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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Transmission and Multiplexing 

(TM). 

The present document is part 2 of a multi-part deliverable covering the Transmission and Multiplexing (TM); Access 
transmission systems on metallic access cables; Very High Speed Digital Subscriber Line (VDSL), as identified below: 

Part 1: "Functional requirements"; 

Part 2: "Transceiver specification issue 2". 



1 Scope 



The present document specifies requirements for transceivers that provide very high bit-rate digital transmission on 
metallic, unshielded, access network wire pairs. The technology is referred to as Very high speed Digital Subscriber 
Line (VDSL). 

This present document is part 2 of the specification for VDSL and is applicable to metallic access transmission systems 
designed to provide multi-megabit/s digital access over part of the existing, unshielded, metallic access network. It is 
concerned with the specification of the line-code and duplex method which enable the requirements stated in 
TS 101 270-1 to be met. 

The present document allows the VDSL transceiver to be implemented using either Single Carrier or Multi-Carrier 
modulation schemes. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

aggregate bit rate: data rate transmitted by a VDSL system in one direction 

NOTE 1 : The aggregate data rate includes both net data rate and overhead used by the system for cyclic redundancy 
checks, the embedded operations channel, VDSL overhead channel, synchronisation of the various data 
streams, and fixed indicator bits for operations, administration, and maintenance. 

NOTE 2: The aggregate data rate does not include forward error correction code redundancy. 
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asymmetric: condition occurring when the bit rate supported in one transmission direction exceeds the bit rate 
supported in the opposite direction 

NOTE: Typically, asymmetric implies that the downstream bit rate exceeds the upstream bit rate. 

ATM cell: digital information block of fixed length (53 octets) identified by a label at the asynchronous transfer mode 
level 

available bit rate: ATM service whose bit rate varies between upper and lower limits and is characterised by an 
average bit rate 

NOTE: The minimum, maximum, and average bit rates may vary while a connection is established. 
bridged taps: sections of unterminated twisted-pair cable connected in parallel across the cable under consideration 
broadband: service or system that supports data using one or more frequency bands above the POTS band 

NOTE: Broadband typically implies transmission of bit rates greater than 100 kbps. 

constant bit rate: ATM service characterised by a deterministic bit rate that remains constant with time 

downstream: direction from the ONU to the subscriber premises 

DR: Data carrying capacity for a single carrier in an SCM system 

dynamic range: ratio between the largest and smallest usable signals that meet the requirements defined in the present 
document 

errored second: one-second interval of received signal containing one or more bit errors 

fast channel: channel with low latency but less immunity to impulse noise in comparison to the slow channel. In 
contrast to the slow channel the fast channel is not interleaved. 

impulse noise: short-duration noise source characterised by sharp rise and fall times and a large amplitude 

line rate: total bit rate supported by a connection in one direction. Line rate is the sum of the payload bit rate and all bit 
rate overhead required for forward error correction, synchronisation, cyclic redundancy checks, the embedded 
operations channel, the VDSL overhead channel, and fixed indicator bits for operations, administration, and 
maintenance. 

network termination: termination at the subscriber premises of a point-to-point VDSL transmission system 

payload bit rate: total data rate that is available to user data in any one direction 

quality of service: set of parameters characterising the success or failure of an end-to-end connection to meet the 
service contract negotiated for the transfer of ATM cells 

slow channel: channel with high latency and more immunity to impulse noise in comparison to the fast channel. Unlike 
the fast channel, the slow channel is interleaved 

splitter: low-pass/high-pass pair of filters that separate high-frequency (VDSL) and low-frequency (POTS/ISDN) 
signals 

sub-channel: frequency band used by a DMT transceiver. Using an inverse discrete Fourier transform (IDFT), the total 
system bandwidth is partitioned into a set of orthogonal, independent sub-channels 

subscriber premise: location at which the remote transceiver resides 

NOTE: It is presumed that the remote transceiver may be located either inside or outside the subscriber premises. 

superframe: set of successive DMT symbols in multi-carrier modulation 

symmetric: condition occurring when the same bit rate is supported in both transmission directions 

TR: Total data carrying capacity using both carriers in an SCM system 
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unspecified bit rate: "best effort" ATM service for which no traffic parameters are specified and no level of 
performance is guaranteed 

upstream: direction from the subscriber premises to the ONU 

variable bit rate: ATM service whose bit rate is characterised by the average and peak bit rates. These parameters 
remain constant for the duration of a connection 

xDSL: Generic term for the family of DSL technologies, including HDSL, ISDN, ADSL, VDSL, etc. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ADSL Asymmetric Digital Subscriber Line 

ATM Asynchronous Transfer Mode 

ATM-TC ATM Transmission Convergence sub-layer 

ATN Attenuation 

ATP Access Termination Point 

BER Bit Error Rate 

BSR Basic Symbol Rate 

BSS Baseband Spectral Shaping 

CO Central Office (or local exchange) 

CP Customer Premise 

CPE Customer Premises Equipment 

DFT Discrete Fourier Transform 

DMT Discrete Multi-Tone 

DS Downstream 

DSL Digital Subscriber Line (or loop) 

EIA External Interface Adapter 

EOC Embedded Operations Channel 

EEC Forward Error Correction 

FEXT Far-End crosstalk 

FTTCab Fibre To The CABinet 

FTTEx Fibre To The Exchange 

HDLC High-level Data Link Control protocol 

HDSL High-rate Digital Subscriber Line 

HEC Header Error Control 

IB Indicator bits 

IDFT Inverse Discrete Fourier Transform 

ISDN Integrated Services Digital Network 

LT Line Termination 

MIB Management Information Base 

MIB Management Information data Base 

MSB Most Significant Bit 

NEXT Near-End crosstalk 

NMS Network Management System 

NT Network Termination 

NTR Network Timing Reference 

OAM Operation, Administration and Maintenance 

ONU Optical Network Unit 

PDH Plesiochronous Digital Hierarchy 

PMD Physical Medium-Dependent 

PMS Physical Medium-Specific 

PMS-TC Physical Medium-Specific Transmission Convergence layer 

PON Passive Optical Network 

POTS Plain Old Telephone Service 

PSD Power Spectral Density 

PSS Passband Spectral Shaping 

PTM Packet Transfer Mode 

PTM-TC Packet Transfer Mode Transmission Convergence layer 

QAM Quadrature Amplitude Modulation 
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RF Radio-Frequency 

RFI Radio-Frequency Interference 

SDH Synchronous Digital Hierarchy 

SM Service Module 

SNR Signal-to-Noise Ratio 

SOC Special Operations Channel 

SONET Synchronous Optical NET work 

SR Symbol Rate 

STM Synchronous Transfer Mode 

STP Set of Transmission Parameters 

TA Timing Advance 

TBD To Be Determined 

TC Transmission Convergence 

TP Transmission Parameters 

TPS-TC Transport Protocol Specific Transmission Convergence layer 

UNI User-Network Interface 

UPBO Upstream Power Back-Off 

US Upstream 

UTOPIA Universal Test & Operations Physical-layer Interface for ATM 

VDSL Very high-speed Digital Subscriber Line 

VME VDSL Management Entity 

VOC VDSL Overhead Channel 

VTU VDSL Transceiver Unit 

VTU-O VTU at the ONU 

VTU-R VTU at the Remote site 
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Reference models 



4.1 



Interface model 



Figure 1 illustrates the generic interface reference model for the copper access section of the VDSL network. The 
vertical lines indicate the eight specification interfaces. The splitters separate VDSL signals from signals of lower 
frequency services, such as POTS or ISDN signals. 
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to CPE 



Figure 1 : Interface reference model 



4.2 



Protocol model 



4.2.1 Protocol layer model 

The Transmission Convergence (TC) layer is split into a transport protocol specific part (TPS-TC part) and an 
application independent part (the Physical Medium Specific - Transmission Convergence (PMS-TC) part). The 
application independent part also contains the transceiver (PMD) functions. The positions of the different interfaces 
with respect to the VDSL sub-layers are shown in figure 2. The functional blocks described by the present document are 
shown in grey. 



ONU 



Y-O y-R 



NT 




Figure 2: VDSL protocol layer model 



4.2.2 Functional decomposition 



VDSL will find application in the transport of various protocols; the present document covers the transport of ATM and 
STM (SDH) and data packets, but the VDSL core transceiver is capable of supporting future additional applications. 
The internal structures of the different Transport Protocol Specific - Transmission Convergence (TPS-TC) layers are 
application specific. Figure 3 shows the functional decomposition of the VDSL with the associated reference points. 
The grey areas show the functional boundary of the TC layer. 
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Figure 3: Functional decomposition 



4.3 Reference points 

Of the reference points defined below only the U reference point is within the scope of the present document. The V, S 
and T reference points are equipment interfaces described in other standards (e.g. TS 101 272 [9]). 

4.3.1 V reference point 

The V reference point is at the physical network interface between the VTU-O and the ONU. 

4.3.2 U reference points 

ISDN/POTS signals can occupy the same physical media as the VDSL signal by using splitters. Thus, the Uj reference 
point refers to the copper-pair media carrying composite signals, whereas the U2 reference point specifies the VDSL 
modem ports only. 

4.3.3 S and T reference points 

The Access Termination Point (ATP) specifies the protection and distribution cable termination. 

4.4 Deployment configurations 

VDSL serves the general fibre -to-the-node architecture illustrated in figure 4. An Optical Network Unit (ONU) situated 
in the existing access network (or, in some cases, at the local exchange) serves hundreds of customers. Existing 
twisted-pair lines transfer narrowband (for example, POTS or ISDN) and broadband (such as ADSL, HDSL, and 
VDSL) signals between the ONU and Customer Premise (CP). For VDSL applications, a Network Termination (NT) at 
the customer premise is defined as the termination of point-to-point VDSL. The NT provides a standardised set of user 
network interfaces (UNI) for the various applications served by VDSL. In addition, the NT allows the network operator 
to test the network up to the NT to determine if the cause of service problems is inside the CP or between the CP and 
the ONU. 
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Figure 4: General fibre-to-the-node architecture for VDSL 

All twisted-pair lines between the ONU and the NT are considered to be part of the VDSL loop. Thus, any vertical drop 
or rise segments of twisted-pair lines at either the CP or ONU end of the network shall be considered specifically part of 
the loop. 

The NT in figure 4 performs termination of the VDSL modulation scheme, link control and maintenance functions and 
provides one or more application-specific interfaces (S- or T-proprietary) to customer equipment. The reference model 
does not imply specific ownership of the NT equipment by customer or network operator. 
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5 Physical Medium Dependent (PIVID) layer 

5.1 Multi -carrier PMD sub-layer specification 



5.1.1 



PMD functional model 
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Figure 5: Functional model of PMD Sub-layer 

The functional model of the PMD sub-layer is presented in figure 5. 

In the transmit direction, the PMD layer shall receive input frames from the PMS-TC sub-layer. A frame shall contain 
exactly the number of octets that shall be modulated onto one DMT symbol. This shall be an integer number. Each 
sub-carrier has a number of bits assigned to it during initialisation. The bits that are to be transmitted on a sub-carrier 
are encoded into constellation points according to the rules given in clause 5.1.2.5. After encoding, the sub-carriers are 
modulated and summed using an IDFT. The resulting digital signal is cyclically extended and windowed before being 
sent toward the transmission medium over the U-interface. 

In the receive direction, the modem shall receive the signal over the U interface and perform the required actions to 
recover the transmitted signal. The data obtained from the demodulator shall be sent to the data decoder that shall 
extract the output data frames. These data frames shall be sent to the PMS-TC layer over the I-interface. 

The management block is responsible for all OAM functions relating to the PMD layer. 
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5.1 .2 VTU-0 and VTU-R functional characteristics 

5.1.2.1 Modulation 

The modulation shall use a maximum number of sub-carriers equal to N^,^ = 256 x 2", where n shall take at least one of 
the values 2, 3, 4. Optionally, when use of the band below 138 kHz is allowed for upstream transmission, n can also 
take the values or 1. Disjoint subsets of the Nj,|, sub-carriers are defined for use in the downstream and upstream 
directions. These subsets are determined by the frequency plan (defined in TS 101 270-1 [1]). The exact subsets of 
sub-carriers used to modulate data in each direction are determined during initialisation based on management system 
settings and the signal-to-noise ratios (SNRs) of the sub-channels. In many cases the number of sub-carriers used in a 
direction will be less than the maximum number allowed by the partitioning. 

5.1.2.1.1 Sub-carriers 

The frequency spacing, Af, between the sub-carriers is 4,3125 kHz, with a tolerance of 50 ppm. The sub-carriers are 
centred at frequencies f = k x Af, where k, the tone index, takes the values 0, 1, 2,.., N^,^ -1. Tone spacing other than 
specified above is for further study and can be considered to meet future requirements. 

5.1.2.1.2 Data sub-carriers 

Transmission may take place on up to N^,^ -1 sub-carriers. The sub-channel centred at DC is not used. The number of 
sub-carriers may be reduced, depending on the need to notch transmission in the amateur radio frequency bands, the 
presence of a POTS or ISDN splitter, PSD masks, implementation specific filters and services to be provided. 

5.1 .2.1 .3 Modulation by the Inverse Discrete Fourier Transform (IDFT) 

The encoder generates N§(;, complex values Zj(/ = 0,...,Nj(-^- 1), including the zero at DC because the sub-carrier 
centred at DC is not used. To generate real, time-domain values x-^ using a complex-to-real IDFT, the set of 
frequency-domain values Zj is augmented to generate a new vector Zjr. The vector Zj. is Hermitian. That is, 

and 

Z. = conj (Zj^ _,.) , / = Nsc, ■■; 2Nsc-i 

The Nyquist frequency is not modulated, therefore Z\ = for / = A^^^- The vector Z/ is transformed to the time domain 
by an inverse discrete Fourier transform (IDFT). The modulating transform defines the relationship between the 2Ngf^ 
real, time-domain values Xj, and the 2Ng(^ complex numbers Zj': 



2N,r-l 



2jiki 



^' "SC •■ J 



i=0 

5.1 .2.2 Cyclic extension 

The last Lcp samples of the IDFT output Xj^ shall be prepended to the 2Ng(j time-domain samples x^ as the cyclic prefix. 
The first Lcs samples of x^ shall be appended to the block of time-domain samples as the cyclic suffix. 

The first (3 samples of the prefix and last P samples of the suffix are used for shaping the envelope of the transmitted 
signal. The maximum value of P is 16 x 2", with values of n as defined in clause 5.1.2.1. The windowed parts of 
consecutive symbols overlap (P samples). 
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Figure 6: Cyclic extensions, windowing and overlap of DMT symbols 

Figure 6 illustrates the relationships between the cyclic extension, prefix, suffix and p. The cyclic extension length, Lcb, 
is LcE = Lcp + Lcs - P samples. 

The values Lcp, Lcs and P must be chosen in order to satisfy the equation (Lcp + Lcs - P) = m X 2""*"^ where m is an 
integer value. The modem shall support a cyclic extension length (L^g) equal to 40 X 2". Other values are also allowed. 

In all cases, P < Lcp and P < Lcs. In the (optional) synchronous mode of operation, the size of the non-windowed part of 
the suffix shall be the same for all modem pairs in a binder group and its duration shall be equal to the propagation 
delay (one way) of the longest line in the binder. This means that VTU-Os and VTU-Rs operating in the same binder 
have a common frame clock and all transceivers start transmission of DMT frames at the same time. 

Table 1 lists example values for the number of samples in the cyclic extension as a function of the total number of 
sub-carriers. With these values each VDSL frame (i.e. DMT symbol H- cyclic extension) has a duration of 250 |is, 
irrespective of the sampling rate. 

Table 1 : Selection of cyclic extension as a function of the number of sub-carriers 

to achieve a 4 kHz symbol rate 



Number of sub-carriers Ng^ 


Cyclic extension length 
(in samples) 


256 


40 


512 


80 


1 024 


160 


2048 


320 


4096 


640 



The symbols shall be transmitted at a rate equal to: 



/,= 



IxN^cXAf 



lxN,c+Lcp + Lcs-P 



5.1.2.3 



Synchronisation 



5.1.2.3.1 



Pilot tone 



Use of a dedicated pilot tone is optional. During initialisation, the VTU-R shall select a sub-channel to use for timing 
recovery. The VTU-R may require a dedicated pilot tone on which data shall not be transmitted, or it may be capable of 
performing timing recovery using sub-channels that support data. If the VTU-R requires a dedicated pilot tone, it 
indicates its choice of pilot tone to the VTU-O during initialisation (clause 8.2.6.3.1.4). The VTU-O then transmits the 
4QAM value of 00 on that tone during every symbol. 
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5.1.2.3.2 Loop timing 

The VTU-R shall loop time its local sampling clock to the pilot selected during initialisation. 

5.1.2.3.3 Timing advance 

VTU-R transmitters shall be capable of implementing an offset called Timing Advance (TA). The TA forces the 
VTU-OA^TU-R pair to start transmissions of frames in opposite directions simultaneously. The timing advance shall be 
equal to the propagation delay from the VTU-O to the VTU-R. It shall be calculated by the VTU-R during initialisation 
(clause 8.2.4.1). The TA is subtracted from the received symbol start time, and the result is used as the VTU-R's 
individual symbol start time so that both the VTU-O and VTU-R transmitters start transmitting each DMT frame at the 
same time. 

Note that timing advance shall be applied at the U2 interface to obtain the desired orthogonality between transmit and 
receive signals. 

5.1 .2.3.4 Synchronous mode (optional) 

In synchronous mode, all VTU-O transceivers on the same cable binder shall transmit with respect to a common symbol 
clock, and thus start the transmission of DMT symbols at the same time. The symbol clock, which may be derived from 
a reference clock, shall be phase synchronous at all VTU-Os in a shared cable with a 1 )J.s maximum phase error 
tolerance. The VTU-R shall extract the symbol clock from the received data. Timing advance (clause 5.1.2.3.3) shall be 
used to correct the VTU-R symbol timing to synchronise VTU-O and VTU-R transmissions. 

In synchronous mode, near-end crosstalk (NEXT) due to other (synchronised) VDSL systems is orthogonal to the 
desired signal on every line. 

5.1 .2.4 Power back-off in the upstream direction 

To mitigate the effects of FEXT from short lines into long lines in distributed cable topologies, upstream power 
back-off shall be applied. Transceivers shall be capable of performing frequency-dependent power back-off. 

The upstream power back-off method is defined by a reference PSD (PSDref) at the VTU-O. The reference PSD shall 
be set using the management interface and shall be transmitted from the VTU-O to the VTU-R (clause 8.2.4.2.1.1). 

The mechanism for power back-off shall comply with the procedure in TS 101 270-1 [1]. This shall be implemented as 
described below. 

The VTU-R shall estimate the insertion loss of the upstream bands based on the received downstream signals. The 
shape of the LOSS function (or the equivalent electrical length) shall be derived from the estimated insertion loss. The 
VTU-R shall compute the transmit PSD by dividing the reference PSD in the upstream bands by the estimated LOSS 
function. The VTU-R shall find the lower of the two values of the computed PSD and the transmit PSD limit for each 
tone in the upstream direction. The resulting PSD for each tone shall be used for the initial upstream transmit PSD. The 
PSD received by the VTU-O should equal the reference PSD. Upon receiving signals from the VTU-R the VTU-O shall 
compare the actual received PSD to the reference PSD. If necessary, it shall instruct the VTU-R to fine-tune its PSD. 

The VTU-O shall also have the capability to impose a maximum allowed transmit PSD at the VTU-R. This maximum 
transmit PSD shall be set by the management interface and transmitted from the VTU-O to the VTU-R during 
initialisation. The management interface at the VTU-O shall select one of these two methods. If the upstream power 
back-off is defined as a maximum transmit PSD at the VTU-R, the VTU-R shall also comply with the transmit PSD 
limits given in TS 101 270-1 [1]. 

5.1.2.5 Constellation encoder 

An algorithmic QAM constellation encoder shall be used to construct sub -channel constellations with a minimum 
number of bits equal to 1 . The maximum number of bits that shall be supported is negotiated during initialisation. The 
maximum number in the downstream direction is B^.^,^j, the maximum number in the upstream direction is denoted as 
Bmax.u- The values of B^^^ and B^^_^ shall be constrained by 8 < B^^j < 15 and 8 < B^.^^_^ < 15. 
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For a given sub-channel, the encoder shall select an odd-integer point (X, Y) from the square -grid constellation based on 
the b bits [vi,.], v^.2,...,Vy,Vo}. For ease of description, these b bits are identified with an integer label whose binary 
representation is (v^.y, v^.2,...,Vy,Vo). For example, for b=2, the four constellation points are labelled 0, 1, 2, and 3 
corresponding to (vy,Vo) = (0,0), (0,1), (1,0), and (1,1), respectively. 



5.1.2.5.1 



Even values of b 



For even values of b, the integer values X and Y of the constellation point (X, Y) shall be determined from the b bits 
{vh-i, Vh.2,---,vj,vo} as follows. X and Y are the odd integers with twos-compliment binary representations 
(vh-i, Vh-s, ..., V], 1) and {vb.2, vt.4, ■■■, vo, 1), respectively. The most significant bits (MSBs), vt-i and v;,.2, are the sign bits 
for X and Y, respectively. Figure 7 shows example constellations for fo = 2 and b = A. 
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Figure 7: Constellation labels for b = 2 and b = 4 

The 4-bit constellation can be obtained from the 2-bit constellation by replacing each label n by the 2x2 block of labels: 

An+\ 4n + 3 

An An + 2 

The same procedure can be used to construct the larger even-bit constellations recursively. 
The constellations obtained for even values of b are square in shape. 

5.1.2.5.2 Odd values of b, b = 1 or b = 3 

Figure 8 shows the constellations for the cases b =\ and b = T>. 
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Figure 8: Constellation labels for b = 1 and b = 3 
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5.1.2.5.3 



Odd values of b, b > 3 



If b is odd and greater than 3, the 2 MSBs of X and the 2 MSBs of Y are determined by the 5 MSBs of the b bits. Let 
c = (b+l)/2, then X and Fhave the twos-comphment binary representations (X„ Xc-i, vt.4, Vb-6,---,V3, vy, 1) and 
(Ja Y^.i, Vh.s, Vfc.7, Vh.g,...,V2, Vg, 1), where Xf. and 7^. are the sign bits of X and F respectively. The relationship betweenX„ 
X^.j, Y„ Y^.i, and v^-h Vb-2,--;'^b-5 is shown in table 2. 

Table 2: Determining the top two bits of Xand Y 



Vb-i, Wb-2,— il^b-5 


Xc, Xc-l 


Vc, Vc-1 


00000 


00 


00 
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00 
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Figure 9 shows the constellation for the case b = 5. 
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Figure 9: Constellation labels for b = 5 
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The 7-bit constellation shall be obtained from the 5 -bit constellation by replacing each label n by the 2x2 block of 
labels: 

An+l 4n + 3 

An An + 2 

The same procedure shall then be used to construct the larger odd-bit constellations recursively. 

5.1.2.6 Gain scaling 

A gain adjuster ^i shall be used to effect a frequency-dependent transmit power spectral density (PSD). It consists of a 
fine gain adjustment with a range from approximately 0,75 to 1,33 (i.e. +2,5 dB), which may be used to equalise the 
expected error rates for all the sub-channels. Each point {X], Y\}, or complex number Z\=X\+ jY\, output from the 
encoder is multiplied by g\: Z\ = g{Z\. 

Other uses of gain scaling are for further study. 

5.1.2.7 Tone ordering 

Because the DMT symbol has a high peak to average power ratio (PAR), peak values in the signal may be clipped by 
the D/A-converter. To a first approximation, this leads to an additive noise that is comparable with impulse noise (with 
an amplitude equal to the clipped portion, but with opposite sign). This noise will be almost white over all the tones. It 
is likely that the tones with the densest constellations (i.e. the tones with the largest SNR) will be more affected when 
this noise is present. Thus, the occurrence of an error is more likely on these tones due to the smaller distance between 
the constellation points. 

If the dual latency option is supported, bits in the slow buffer shall be assigned to tones with the highest SNRs. With 
this scheme, occasional errors on these tones due to clipping can be corrected by the combination of interleaving and 
RS coding. The bits on tones with smaller constellations are less likely to be in error due to clipping noise and therefore 
support bits from the fast buffer. 

The "tone-ordered" encoding shall first assign all the bits from the fast buffer to the tones with the smallest number of 
bits assigned to them, and then assign all the bits from the interleaved buffer to the remaining tones. All tones shall be 
encoded with the number of bits assigned to them. Therefore, a single tone may support a mixture of bits from the fast 
and slow buffers. 

The ordered bit table b'l shall be based on the original bit table bi as follows: 

Forfe = OtoB^^^j„^^ 

• From the bit table, find the set of all / with the number of bits per tone b, = k; 

• Assign bi to the ordered bit allocation table in ascending order of /. 

A complementary de -ordering procedure shall be performed by the receiver at the other end of the line. It is not 
necessary to transmit the results of the ordering procedure to the receiver because all the information required to 
perform the de -ordering already exists at the receiver. 

If only one single-latency channel is supported, bits are assigned to tones starting from the lowest available frequency 
based on the original bit table bj. 

Figure 10 illustrates how the bits are extracted from the fast and interleaved data buffers when tone -ordering is applied. 
In this example, both fast and interleaved buffers are one octet long. Following the above rule, the first bits are taken 
from the fast buffer, starting from the LSB and are placed on the tones with the lowest number of bits assigned to it. The 
fourth tone to be loaded (carrying b3' bits) takes bits from both the fast and interleaved buffers. 



£75/ 



24 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



Data Frame Buffer 



^4^ 



LSB 



MSB 



dO dl d2 d3 d4 d5 d6 d7 



Slow Data 



LSB 



MSB 



dO dl d2 d3 d4 d5 d6 d7 



5.1.2.8 



5.1.2.8.1 



bO' bl' b2' b3' b4' 

Figure 10: Bit extraction after tone ordering 
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In the default mode, emissions from both the VTU-O and VTU-R shall be controlled by constraining the transmitted 
PSD in frequency bands allocated in the over-the-air spectrum for amateur radio transmissions. An optional mode 
enables sub-channels within one or more of the amateur radio bands for data transmission. This optional mode, which 
can be invoked only by the network operator via the network management interface, improves VDSL performance 
when emissions into the amateur radio bands are not of concern. 

5.1 .2.8.2 Power Spectral Density of all signals 

The VDSL transmit PSD in the passband shall not exceed the PSD as defined in TS 101 270-1 [1]. 

Avoidance of the amateur radio bands (as described in clause 5.1 .2.8. 1) is mandatory; support of an option to enable 
transmission in one or more amateur radio bands is discretionary. 

The VDSL PSD in the POTS and ISDN bands shall comply with the requirements given in TS 101 270-1 [1]. 

5.1 .2.8.3 Wideband launch power 

The wideband launch power shall comply with TS 101 270-1 [1]. 

5.2 Single carrier PIVID sub-layer specification 

The Physical Medium-Dependent (PMD) sub-layer specifies the modulation schemes, the duplexing method and the 
electrical characteristics of the signal to be transmitted over the physical medium. 

5.2.1 Basic principles 



5.2.1.1 



Functional model 



The VDSL transceiver functional model is presented in figure 1 1 . This model defines the PMD sub-layer between the 
I_0 (I_R) and U2_0 (U2_R) reference points respectively. 

In the transmit direction the input frame (clause 6.5.1) coming from the PMS-TC via the I-interface, is split into two 
streams with data rate ratio N2/N2, where N^, N2 are integers. Each stream is encoded, modulated and sent onto the 
transmission line via the Uj -interface. Each stream is transmitted in a separate frequency band, defined by the 

corresponding band-pass filter. The signal transmitted in a certain band is called a "Carrier". Up to two carriers can be 
transmitted in both upstream and downstream directions. If the first carrier can transmit all the input data the second 
carrier is not used. In this case (N^ = 1, N2 = 0) both the splitter and the multiplexer are bypassed. 

In the receive direction the carriers received in both bands are demodulated, decoded and multiplexed into the output 
transmission frame, which has the same structure as the input frame. The output frame is sent towards the PMS-TC via 
the I-interface. 

The band-pass filters in the transmit and receive directions restrict the transmit out-of-band power to prevent crosstalk 
between the US and DS carriers. 
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The PMD management block provides all the OAM functions required by the PMD. The exchange of management 
information between the VTU OAM entity and PMD management block is accomplished via the I-interface. 




To the transmission media 



NOTE: The name of the carrier (carrier 1 and carrier 2) is not associated with any particular frequency band. If 
additional spectrum either below Iq or above f5 (see TS 101 270-1 [1]) is used the existing carriers will be 

extended. 

Figure 11 : VTU PMD Sub-layer Functional Model 



5.2.1.2 



Timing 



The transmitters of both carriers in the VTU-O shall use a transmit clock which is derived from the network clock 
(e.g. SONET clock, SDH clock, PON clock) to allow end-to-end network synchronisation. If the network clock is not 
available, the VTU-O shall use a locally generated master clock with a maximum tolerance of ±50 ppm. 

The transmitters of both carriers in the VTU-R shall use a transmit clock which is derived from the received data clock 
of either the first or the second downstream carrier (loop timing). If the received data clock is lost during the 
steady-state transmission, the VTU-R shall use a locally generated clock with a maximum tolerance of ±50 ppm to 
perform the link activation. 



5.2.2 Transmit functionality 



5.2.2.1 



Frame splitting 



The splitter shall originate a special frame (PMD-frame) for both transmitted carriers prior to encoding to compensate 
for the propagation delay difference between the two carriers at the receive side. The PMD-frame is independent of the 
carrier data rate. It consists of a total of 405 octets: a 2-octet Syncword, and a 403-octet data field combined from 
different fields of the input frame (figure 11). The same splitting procedure is applied for both the upstream and 
downstream carriers. The PMD-frame Syncword contains Syncl and Sync2 octets (clause 6.5.1.3). 

The PMD-frame structure and mapping of the input frame (figure 15) into the PMD-frame for both carriers are 
presented in figure 12. The splitter maps the input frame into two PMD-frames to be transmitted by two carriers with 
data rate ratio of N1/N2. The procedure starts from the frame alignment octet Syncl of an auxiliary input frame (input 
frame #1 in figure 12). The Syncl octet and the following Sync2 octet from the input frame are sent into both carrier- 1 
and carrier-2 streams to form their own Syncwords. All Syncl, Sync2 octets of the input frames following frame #1 
shall be removed. 
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The Nj octets of the input frame #1 following the Sync2 octet shall be mapped into carrier-1 and the N2 following 
octets of the input frame shall be mapped into carrier-2. A repetition of this process forms the information field of the 
PMD-frame. An inverted Syncword shall be inserted into each PMD-frame (both carrier-1 and carrier-2) after every 
403 data octets inserted into its information field. If fewer than Nj or N2 octet positions remain at the end of a given 

PMD-frame, the next group of N^ or N2 octets is split between the end of that PMD-frame and the beginning of the next 
PMD-frame, as shown in figure 12. 

The splitting process is cyclic. A cycle contains (NjH-N2) input frames. During the splitting cycle exactly Nj frames are 
mapped into the carrier-1 and exactly N2 frames are mapped into the carrier-2. For simplicity the start of the 
PMD-frames of both carriers in figure 12 are aligned with the Syncl octet of the input frame #1. 



PMD-frame of carrier 1_ 
(405 octets) 



Syncword 
2 bytes 



Frame #1 



A »k. 



N,-j 



- J is between and (N1-1) 



Inverted 

Syncword 

2 bytes 



N, 



N, 



Frame #N, 



■ Input frame 



Syncword 
2 bytes 



Frame #1 



A A 



N-x 



- X is between and (N-1 }, N=N^ or Nj 



Syncword 
2 bytes 



Frame #2 



Frame #(N,+N2; 



_ PMD-frame of carrier 2 



(405 octets) 



Syncword 
2 bytes 



N,-y 



y is between and (N2-1 ) 



Inverted 
Syncword 
2 bytes 



-T\ 



Frame #1 



Frame #N, 



Splitting cycle = (N,+Np) input transmission frames 



Syncword 
2 bytes 



Frame #1 



Syncword 
2 bytes 



Frame #1 



Syncword 
2 bytes 



Frame #1 



Figure 12: PMD-frame Format 

The time difference between the beginning of the splitting cycles of the PMD-frames transmitted by carrier 1 and 
carrier 2 respectively, measured at the output of the transceiver, shall be less than 

Max\^ -I- 40 X Ahs^^ - T^ ),20} l^s, where Tj = l/SRj, T2 = I/SR2, SRj and SR2 are the symbol rates of carriers 1 
and 2 respectively. The timing difference shall be measured with respect to the start of the first bit of the PMD frame #1 
for each carrier. 

The modem shall at a minimum support values of Nj and N2 that provide the bit rates (DR) listed in tables 6, 8, 10 and 
12. 

NOTE: Using the greater common divisor G = gcd(DRj,DR2) of the bit rates DRj, DR2 of carrier 1 and carrier 2, 
the values of N^ and N2 shall be DR^/G and DR2/G respectively. 
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5.2.2.2 



Coding and modulation 



The transmission capability and timing between the VTU-O and the VTU-R over both carriers in both the downstream 
and upstream directions is provided by using Single Carrier Modulation (SCM) with either Pass-band Spectral Shaping 
(PSS) or Base-band Spectral Shaping (BSS). The transmitters in the VTU-O and VTU-R may be implemented using 
either PSS or BSS. The receivers in the corresponding VTU-R and VTU-O are responsible for detecting the type of 
spectral shaping and decoding either PSS shaped or BSS shaped incoming signals. 

The functional blocks shown in figures 13 and 14 describe the coding and modulation functionality. Any 
implementation that produces the same functional behaviour at the transmitter output is equally valid. The input data 
stream shall be encoded into two symbol streams Ij^ and Qj^, where n designates the n* symbol period. The symbol 
streams Ij^ and Qj^ shall be modulated using the corresponding spectral shaping and sent into the transmission media via 
a band-pass filter. 

Figure 13 shows the block diagram of an SCM transmitter using PSS while figure 14 shows the block diagram of an 
SCM transmitter using BSS. 
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Figure 13: Block Diagram of a SCIU! Transmitter Using PSS 
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Figure 14: B\ocW Diagram of a SCIV! Transmitter Using BSS 



5.2.2.2.1 



Constellation encoder 



The encoding procedure shall treat the input data as a serial stream of bits with the most significant bit first. For a given 
constellation of size 2^^, a group of M consecutive bits {bj,b2,. . .bjyj} of the input data shall be encoded into one 
symbol, and consecutive groups of M bits are encoded into consecutive symbols as illustrated in figure 15. Differential 
quadrant encoding shall be used. For M = 1, every input bit shall be encoded as specified in the upper part of table 3. 
The two possible values of {bj } represent the transition of the symbol between the first and third quadrants (figure 16). 

For M > 1, the first two bits {bj,b2} shall be encoded as described in the lower part of table 3. The four values of 
{b2,b2} represent the quadrant transition of the symbols. The remaining (M-2) bits shall be encoded in accordance with 
the relevant constellation diagrams. The constellation diagrams for 4, 8, 16, 32, 64, 128, 256 and 512 points are given in 
figures 16 through 23. The constellation diagram for 1 024 points is similar to other constellations with even values of 
M, the encoding is described in table 4. 
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NOTE 1 : For constellation sizes 32 to 1 024 the second, third and fourth quadrant mappings shall be derived from 
the mappings in the first quadrant shown in figures 19 to 23 and table 4 by rotating the quadrant 
counter-clockwise by 90°, 180°, and 270°, respectively. 
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Figure 15: Bit to symbol mapping 



Table 3: Differential Encoding of bi, b2 
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Figure 16: 4-point Constellation with 
Differential Bit Encoding 
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Figure 18: 16-point Constellation and 
Bit Mapping 
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Figure 17: 8-point Constellation and 
Bit Mapping 
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Figure 19: First Quadrant of 32-point 
Constellation and Bit Mapping 
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Figure 20: First Quadrant Of 64-Point 
Constellation and Bit Mapping 



Figure 21 : First Quadrant of 128-point 
Constellation and Bit Mapping 



Q. 

H15-- « 

000100 

H3- • 
000101 



Hll-- 



+9 



+7 



+5 



+3 



+ 1 



000111 



- • 

000110 



- • 

000010 



- • 

000011 



- 

000001 



- • 

000000 



001100 



001101 



001111 



001110 



001010 



001011 



001001 



001000 



011100 



011101 



011111 



011110 



011010 



011011 



011001 



011000 



010100 



010101 



010111 



010110 



010010 



010011 



010001 



010000 



110100 



110101 



110111 



110110 



110010 



noon 



110001 



iioooo 



111100 



111101 



111111 



111110 



111010 



t 

111011 



111001 



111000 



101100 100100 



101101 100101 



101111 100111 



101110 100110 



101010 100010 



t • 

101011 100011 



101001 100001 



101000 loopoo 



+1 



+3 



+5 



+9 



ns 



Figure 22: First Quadrant of 256-Point Constellation and Bit Mapping 
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Figure 23: First Quadrant of 512-Point Constellation and Bit Mapping 
Table 4: First quadrant of 1 024-point constellation bit mapping 



1^, (binary representation) 


Qn 


(binary representation) 


'n ^ ^1 \ ^3 ^4 ' 




Qn = yi yg Vs V4 1 


Xl=b3 




y^=bj 


Xg = X^ + b4 




y2 = Vi + bg 


X3 = X2 + bg 




ys = Va + bg 


X4 = X3 + be 




y4 = y3 + bio 



NOTE 2: The following example clarifies the usage of table 4: 

for bjb^bjbgb^bgbgbjQ = 00000001, we get x^ = X2 = X3 = X4 = 0, Yi = y2 = Ya = 0, y4 = 1 and I^^ = 00001 
(bin) = 1 (dec) and Qn = 00011 (bin) = 3 (dec). SimilarlY, a constellation point with l^ = 1 and Qn = 3 will 
be coded 00000001 (bin). 



5.2.2.2.2 



Modulator 



If the transmitter uses PSS then the two encoded streams Ij^ and Qj^ are sent to pass-band in-phase and quadrature 
shaping filters, respectivelY. The output of the in-phase filter and the inverted output of the quadrature filter are summed 
to form a signal with two orthogonal components. The result is passed through a band-pass filter, and then transmitted 
onto the media. 

If the transmitter uses BSS then the two encoded streams, I^ and Q^, are sent to low-pass shaping filters. The output of 
the filter for the in-phase path is heterodyned with a cosine carrier signal. The output of the filter for the quadrature path 
is heterodyned with a sine carrier signal of the same frequency. The outputs of the two paths are subtracted to form a 
signal with two orthogonal components. The result is passed through a band-pass filter, and then transmitted onto the 
media. 

The amplitudes of Ij^ and Qj^ components in the transmitted constellations shall maintain the relative values of 1, 3, 5, 7, 

9, ... 31 with a tolerance of ±0,06 relative to these values, as it depicted in the constellation diagrams in figures 16 to 23 
and table 4. 
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5.2.2.2.2.1 Symbol rates and carrier frequencies 

Both the downstream and upstream Symbol Rates (SR) are scaleable. All available symbol rates are multiples of the 
Basic Symbol Rate (BSR): 

SR = sx BSR, 

where s is an integer, BSR = 33,75 kBaud. 

The carrier signal frequencies/c for transmitters using BSS shall be an integer multiple of ViBSR: 

fc='/2BSRxk, [MHz], 

where k is an integer. The resulting/c shifting granularity is equal to 16,875 kHz. 

NOTE: The value of SR/fc shall be an exact ratio of two integers under all possible frequency tolerances. The 
particular values of fc and SR for standard transmission profiles can be found in clause 5.2.5.2. 

5.2.2.2.2.2 Spectral Shaping Filters 

For both BSS and PSS filters, the low-pass, the in-phase and the quadrature filters shall have an excess bandwidth of 
a = 0,20 (square-root raised-cosine approximation of the frequency response, see table 5). 

The BSS low-pass filter (see figure 14) impulse response is an approximation of: 

sin(;r — ) + ( — )cos(;r — ) 
„/,^ = 5T 5T 5T 

^^^ t At 2 

where T = 1/SR is the symbol period. 

The impulse response of the PSS in-phase filter (see figure 13) is an approximation of: 

/(0 = ^(0xcos(2;^/). 

The impulse response of the PSS quadrature filter (see figure 13) is an approximation of: 

nt) = git)xsmi27if^t), 

where /c is the centre frequency of the transmit signal, and is also equal to the carrier frequency /c used in the 
corresponding BSS transmitter. 

5.2.2.3 Carrier spectral shaping 

The transmit signal of any carrier inside the transmit band shall meet the power spectrum template, G, and the group 
delay distortion template, D, defined in table 5. The nominal, lower and upper limits of the attenuation and group delay 
distortion are defined as a function of the normalised frequency x, where: 

SRI2 
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Table 5: Power Spectrum Template 



Normalised frequency 
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G(min) 
dB 


G(nom) 
dB 


G (max) 
dB 
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< -4,5T 


1,1 
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-6 


<-5T 


1,15 
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<-8T 


1,2 




OO 


<-20 
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oo 


<-30 


1,4 




oo 


<-40 


1,5 




oo 
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NOTE 1 : The absolute value of the nominal transmit PSD corresponds to the template level of clB. 
NOTE 2: The part of the templates for G and D defined by |x| < 1 ,2 account for the effects of all the filters 

shown in figure 13 and 14. 
NOTE 3: The values for the PSD given in table 5 for |x > 1 ,2 may not be sufficient to meet the generic 

requirements for the out-of-band PSD. The band-pass filter shall provide the additional 

out-of-band filtering if necessary. 
NOTE 4: The templates only relate to flat-shaped and unnotched transmit PSDs. Templates for non-flat 

transmit PSDs are for further study. 
NOTE 5: Dmin is the minimum group delay within the in-band spectrum: 

Dmin = Min{D(x), x < 1.2}. 



5.2.3 Receive functionality 

The receiver demodulates and decodes the incoming signal of both carriers received from the transmission line, and 
multiplexes them into an output frame (figure 1 1). The VTU-R modem receiver functionality shall include recovery of 
the symbol timing. 

Both the demodulation and decoding process shall be matched with the modulation and encoding process respectively. 
The demodulator shall automatically recognise whether PSS or BSS shaping is applied at the transmitter side. 

The PMD-frame delineation algorithm of the receiver is proprietary. 

The multiplexing procedure combines PMD-frames of the carrier-1 and the carrier-2, as presented in figure 12, into the 
original transmission frame as described in clause 6.5.1, and reconstructs the original frame alignment octets Syncl, 
Sync2. The multiplexing procedure shall be matched with the splitting procedure as specified in clause 5.2.2.1. 

The receiver must tolerate a delay difference caused by the transmitter and the transmission path (twisted pair line, 
splitters etc). The latter is usually less than 1 jj,s. 
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5.2.4 Interface specification 

5.2.4.1 l-interface 

The I_0 and I_R reference points define interface between the PMD and PMS-TC sub-layers. Both interfaces are 
identical and described in clause 6.3.2. 

5.2.4.2 U1 -interface (Transmission Media Interface) 

5.2.4.2.1 Transmit signal power 

The nominal power of the transmit signal for either all upstream or all downstream carriers shall not exceed the limit 
specified in TS 101270-1 [1]. 

5.2.4.2.2 Transmit signal Power Spectral Density 

The transmit Power Spectral Density (PSD) shall comply with the masks Ml and M2 defined in TS 101 270-1 [1]. 

5.2.4.2.3 Transmit PSD control 

All PSD control options shall be available independently in both the upstream and downstream directions by the 
Network Operator via the management system. Some of these options may be established automatically, upon the 
corresponding link activation procedure. 

5.2.4.2.3.1 PSD 

Control of the transmit PSD is available for all upstream and downstream carriers in both transmission directions, as 
specified in clause 7.5.3.3.1 

The particular value of the PSD for any application and deployment scenario is limited by the transmit signal power 
value, as defined in clause 5.2.4.2.1, and by the applied PSD mask, as defined in TS 101 270-1 [1] (PSD masks Ml, 
M2). 

5.2.4.2.3.2 Transmit PSD notches 

To reduce the effect of the radiated emission from a VDSL modem on amateur radio services the PSD of the transmit 
signal within amateur radio bands shall be able to be decreased to below -80 dBm/Hz. The minimum number of notches 
that can be applied simultaneously in both directions shall be four. The corresponding amateur frequency bands are 
presented in TS 101270-1 [1]. 

The order of the transfer function that implements a notch filter (a stop-band filter) shall not be higher than 6* order per 
notch (6 or less poles per notch). Any notch may be applied independently by the corresponding command during the 
system configuration (clause 7.5.3.3). 

5.2.4.2.3.3 Upstream Power Back-Off 

5.2.4.2.3.3.1 Introduction 

Upstream power back-off will be provided by the VTU-R in accordance with the up-stream power back-off 
requirements specified in TS 101 270-1 [1] By implementation, two types of power back-off will be available for both 
upstream carriers independently: 

• Start-up PSD back-off; 

• Steady-state PSD shaping. 
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5.2.4.2.3.3.2 



Start-up Power Back-off 



The start-up power back-off shall only be performed during the Cold-start (clause 8.3. 1.2) by applying a flat transmit 
PSD reduction on the upstream carrier(s) at the beginning of Cold-start activation. The VTU-R receiver shall compute 
the transmit PSD for each upstream carrier (TxPSD_U) autonomously (with no assistance from the VTU-O) based on 
the received downstream signal from the VTU-O using the following rule: 

TxPSD = PSDnEFifc) + LOSSifc) - LOSS_CORR 

where PSDjief and LOSS are defined in TS 101 270-1 [l],/c is the centre frequency of the upstream carrier and 
LOSSjCORR is an additional (6 dB) reduction of the upstream transmit PSD to compensate for possible inaccuracy in 
the estimated electrical length of the loop. 

The VTU-R shall also comply with the upstream transmit PSD limit defined in TS 101 270-1 [1]. 

NOTE: The value of LOSSjCORR depends on the VDSL link transmission parameters used during Cold-start. 
The value of 6 dB is only applicable when using the specified values for DF_STP (table 90). 



5.2.4.2.3.3.3 



Steady-State PSD Shaping 



The Steady-state PSD shaping is intended for fine tuning the upstream transmit PSD during the steady-state 
transmission by an algorithm including an exchange of the related parameters between the VTU-O and VTU-R. The 
PSD shaping algorithm is proprietary and shall comply with TS 101 270-1 [1]. The exchange parameters are the 
following: 



• insertion loss for each carrier; 

• SNR for each carrier. 



The detailed Steady-state PSD shaping method and the other exchange parameters are for further study. 



5.2.4.2.4 



Return Loss 



The return loss shall comply with the requirements specified in clause 8.3.2 of TS 101 270-1 [1]. The return loss mask 
for any carrier, in both the transmit and receive directions, is shown in figure 24. 

The return loss shall be measured on a resistive test load of /?v (135 il ± 0,2 %) while the tested implementation of the 
VTU is powered. 
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NOTE: 



/b-0,6SR fc-0,4SR fc fc+0,4SR fc+0,6SR 

See clause 5.2.5.2 for the particular fc and SR values for standard transmission profiles. 

Figure 24: Return Loss Mask 



5.2.4.2.5 



Output Signal Balance (OSB) 



Output Signal Balance (OSB) shall comply with the requirements in clause 8.3.3 of TS 101 270-1 [1] in the VDSL band 
of each transmitted carrier, as defined in clause 5.2.5.1.3 (from/c - 1/2SR to/c H- 1/2SR). 
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5.2.5 Transmission profiles 

Transmission profile is a set of parameters, which define the following transmission characteristics of the VDSL link: 

• transport capacity; 

• spectral allocation; 

• PSD mask; 

• deployment characteristics. 

5.2.5.1 Transmission profile specification 

5.2.5.1.1 Profile code 

Each profile is specified by a special code consisting of 8 characters [XY-X1X2X3X4X5-X6]. 

The first two characters XY define the profile type and coincide with the names of standard classes of operation A1-A4 
(Class 1, asymmetric) and S1-S5 (Class II, symmetric) as specified in TS 101 270-1. The six other characters have the 
following description. 

1) Xi is a profile sub-number with an integer value between and 3. Sub-number shall be used for standard 
profiles (clause 5.2.5.2), providing the original bit rate for the given profile type XY. Sub-number 1 shall be 
used for profiles with reduced bit rate in the US. Sub-number 2 shall be used for profiles with a reduced bit 
rate in the DS. Sub-number 3 shall be used for profiles with reduced bit rate in both US and DS. 

2) X2 specifies the spectral allocation scheme and has a value between and 3. The following types of spectral 
allocation are defined: 

- "0" for DS-US-DS-US type using carriers ID, lU, 2D, 2U; 

- "1" for DS-US-DS type using carriers ID, lU, 2D; 

- "2" for DS-US type using carriers ID, lU; 

- "3" for DS-US-US type using carriers ID, lU, 2U. 

3) X3 specifies whether notching of amateur radio bands is applied or not and has a value of N (notched) or O 
(unnotched). X3 has value "X" to indicate that either value may be applied. 

4) X4 specifies whether the transmit signal occupies the ADSL frequency band. It shall have a value of "N" if it 

occupies the spectrum, the value "A" if FTTCab variant A is used and the value "B" if FTTCab variant B is 
used. 

5) X5 - optional - specifies whether the profile is intended for FTTEx, FTTCab or for both applications and can 
have values E, C or G respectively. 

6) Xg is the profile spectral compatibility marker, which can have values: 

- "M" for profiles utiUsing the VDSL band allocation (see TS 101 270-1 [1]); 

- "Rl" for profiles utilising the optional regional specific band allocation; 

- "R2",''R3"... for profiles utilising other regional band allocations. 

5.2.5.1.2 Bit Rates 

The transmission profile total bit rate (TR) in the corresponding directions is defined by the bit rates (DR) of its carriers 
in either upstream or downstream direction. 

The DR of the particular carrier is defined by the applied symbol rate SR and constellation size C: 
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The TR in a certain direction is defined by symbol rates SRI, SR2 and constellation sizes CI, C2 over both carriers in 
this direction: 

TR = SRi X log2 Ci + 5i?2 X log2 C^ , 
where index 1 or 2 corresponds with carrier 1, 2 respectively. 

The minimum available transmission rate is achieved when both the minimum symbol rate SR = BSR = 33,75 kBaud 
and the minimum constellation size C = 2 are applied. The Basic Bit Rate BBR = 33,75 x C kb/s defines the 
transmission bit rate granularity. 

5.2.5.1 .3 Spectral allocation of the Transmit Signal 

Spectrum allocation of the transmit signal of a carrier with a specific DR is defined by the carrier centre frequency /c 
(clause 5.2.2.2.2.1) and its symbol rate SR. 

In accordance with the transmit filter characteristics described in clause 5.2.2.2.2.2, both carriers of the downstream and 
of the upstream transmit signals shall have a square-root raised-cosine power spectral shaping with 20 % excess 
bandwidth. Thus the lowest frequency (/low) and the highest frequency (fniGH) ^'-'^ ^^'-'^ carrier could be calculated as: 

f,ow=fc-0,6xSR, /„,,,= f,+0,6xSR. 

The 3dB-bandwidth of a carrier occupies the frequency range between: 

/c-0,5x5i?and fc+0,5xSR. 
5.2.5.2 Standard Transmission Profiles 

Standard transmission profiles are intended to provide both symmetric and asymmetric operation (services) with the 
payload rates defined in TS 101 270-1 [1]. A specific standard profile is defined for each payload rate utilising either 
the VDSL band allocation or the optional regional specific band allocation. The Symbol Rates (SR), bit rates (DR) and 
band allocation of both carriers for standard asymmetric operation are presented in tables 6 and 7 (VDSL band 
allocation) and tables 10 and 11 (optional regional specific band allocation). The same parameters for standard 
symmetric operation are presented in tables 8 and 9 (VDSL band allocation) and tables 12 and 13 (optional regional 
specific band allocation). 

NOTE 1: The symbol rates, constellation sizes and band allocation recommended in tables 6 to 13 are intended for 
use in either FTTEx or FTTCab (variants A or B) deployments. These parameters can be modified using 
the procedure described in clause 8.3.2 to improve performance in particular loop/noise environments. 

NOTE 2: Standard transmission profiles do not support service at bit rate S5. 
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5.2.5.2.1 



Standard Transmission Profiles - VDSL Band Allocation 



Table 6: Asymmetric Profiles: Bit Rates 



Profile Code 


Carrier 


Symbol Rate 

SR 

(IVIBaud) 


Constell. 
C 


Data Rate 
DR 

(Mb/s) 


Total Rate 
TR 

(Mb/s) 


Maximum 

Payload Rate 

(Mb/s) 


A1-02OAG-M 
A1-02OBG-M 


1D 


1 ,485 (22 X 67,5) 


32 


7,425 


DS 


7,425 


6,637 


1U 


1,215(18x67,5) 


4 


2,43 


US 


2,43 


2,172 


A2-02OAG-M 


1D 


1 ,485 (22 X 67,5) 


64 


8,91 


DS 


10,26 


9,171 


2D 


1,35(20x67,5) 


2 


1,35 


1U 


1,215(18x67,5) 


4 


2,43 


US 


2,43 


2,172 


A2-02OBG-M 


1D 


1,62(24x67,5) 


64 


9,72 


DS 


9,72 


8,688 


1U 


1,215(18x67,5) 


4 


2,43 


US 


2.43 


2,172 


A3-01OAG-M 
A3-01OBG-M 


1D 


1,51875(22,5x67,5) 


256 


12,15 


DS 


16,2 


14,48 


2D 


1 ,35 (20 X 67,5) 


8 


4,05 


1U 


1,215(18x67,5) 


8 


3,645 


US 


3,645 


3,258 


A4-01ONE-M 


1D 


2,16(32x67,5) 


256 


17,28 


DS 


25,92 


23,168 


2D 


1,08(16x67,5) 


256 


8,64 


1U 


1,215(18x67,5) 


16 


4,86 


US 


4,86 


4,096 


NOTE: Payload rate is calculated assuming single latency. 



Table 7: Asymmetric Profiles - Spectrum Allocation 



Profile code 


Carrier 


Carrier frequency 
fc (MHz) 


Lowest 
frequency 

fLow(MHz) 


Highest 
frequency 
/high (MHz) 


PSD 
(dBm/Hz) 


A1-02OAG-M 
A1-02OBG-M 


ID 


2,05875 (61 X 33,75) 


1,17 


2,95 


-61 


1U 


3,8475(114x33,75) 


3,12 


4,58 


A2-02OAG-M 


ID 


2,05875 (61 X 33,75) 


1,17 


2,95 


2D 


6,17625(183x33,75) 


5,37 


6,99 


1U 


3,8475(114x33,75) 


3,12 


4,58 


A2-02OBG-M 


ID 


1 ,92375 (57 x 33,75) 


0,95 


2,9 


1U 


3,8475(114x33,75) 


3,12 


4,58 


A3-01OAG-M 
A3-01OBG-M 


ID 


2,025 (60 X 33,75) 


1,14 


2,94 


2D 


6,17625(183x33,75) 


5,37 


6,99 


1U 


3,8475(114x33,75) 


3,12 


4,58 


A4-01ONE-A 


ID 


1 ,485 (44 X 33,75) 


0,189 


2,781 


2D 


6,075(180x33,75) 


5,427 


6,723 


1U 


3,8475(114x33,75) 


3,12 


4,58 



Table 8: Symmetric Profiles - Bit Rates 



Profile code 


Carrier 


Symbol Rate 

SR 

(MBaud) 


Constell. 
C 


Data Rate 
DR 

(Mb/s) 


Total Rate 
TR 

(Mb/s) 


Maximum 

Payload Rate 

(Mb/s) 


S1-03OAG-M 
S1-03OBG-M 


ID 


1,485(22x67,5) 


32 


7,425 


DS 


7,425 


6,637 


1U 


1,62(24x67,5) 


16 


6,48 


US 


7,29 


6,516 


2U 


0,81 (12x67,5) 


2 


0,81 


S2-03OAG-M 
S2-03OBG-M 


ID 


1 ,485 (22 X 67,5) 


64 


8,91 


DS 


10,26 


9,171 


2D 


1,35(20x67,5) 


2 


1,35 


1U 


1 ,62 (24 x 67,5) 


16 


6,48 


US 


9,72 


8,688 


2U 


1 ,62 (24 x 67,5) 


4 


3,24 


S3-00OAG-M 
S3-00OBG-M 


ID 


1,51875(22,5x67,5) 


256 


12,15 


DS 


16,2 


14,48 


2D 


1 ,35 (20 X 67,5) 


8 


4,05 


1U 


1,62(24x67,5) 


32 


8,1 


US 


16,2 


14,48 


2U 


2,7(40x67,5) 


8 


8,1 


S4-00OAG-M 
S4-00OBG-M 


ID 


1,51875(22,5x67,5) 


1 024 


15,188 


DS 


25,988 


23,228 


2D 


1 ,35 (20 X 67,5) 


256 


10,8 


1U 


1 ,62 (24 X 67,5) 


256 


12,96 


US 


26,46 


23,651 


2U 


2,7(40x67,5) 


32 


13,5 


NOTE: Payload rate is calculated assuming single latency. 
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Table 9: Symmetric Profiles - Spectrum Allocation 



Profile Code 


Carrier 


Carrier frequency 
fc (iVIHz) 


Lowest 
frequency 

fLow(MHz) 


Highest 
frequency 
/high (IVIHz) 


PSD 
(dBm/Hz) 


S1-03OAG-M 
S1-03OBG-M 


1D 


2,05875 (61 X 33,75) 


1,17 


2,95 


-61 


1U 


4,1175(122x33,75) 


3,15 


5,09 


2U 


8,370 (248 X 33,75) 


7,88 


8,57 


S2-03OAG-M 
S2-03OBG-M 


ID 


2,05875 (61 X 33,75) 


1,17 


2,95 


2D 


6,17625(183x33,75) 


5,37 


6,99 


1U 


4,1175(122x33,75) 


3,15 


5,09 


2U 


8,8425 (262 x 33,75) 


7,87 


9,81 


S3-00OAG-M 
S3-00OBG-M 
S4-00OAG-M 
S4-00OBG-M 


ID 


2,025 (60 X 33,75) 


1,14 


2,94 


2D 


6,17625(183x33,75) 


5,37 


6,99 


1U 


4,1175(122x33,75) 


3,15 


5,09 


2U 


9,5175(282x33,75) 


7,9 


11,14 



5.2.5.2.2 



Standard Transmission Profiles - Optional Regional Specific Band Allocation 



Table 10: Asymmetric Profiles : Bit Rates 



Profile Code 


Carrier 


Symbol Rate 

SR 

(MBaud) 


Constell. 
C 


Data Rate 
DR 

(Mb/s) 


Total Rate 
TR 

(Mb/s) 


Maximum 

Payload Rate 

(Mb/s) 


A1-02OAG-R1 
A1-02OBG-R1 


ID 


1,89(28x67,5) 


16 


7,56 


DS 


7,56 


6,757 


1U 


0,81 (12x67,5) 


8 


2,43 


US 


2,43 


2,172 


A2-02OAG-R1 
A2-02OBG-R1 


ID 


2,025 (30 x 67,5) 


32 


10,125 


DS 


10,125 


9,05 


1U 


0,81 (12x67,5) 


8 


2,43 


US 


2,43 


2,172 


A3-01OAG-R1 
A3-01OBG-R1 


ID 


2,025 (30 x 67,5) 


64 


12,15 


DS 


16,47 


14,721 


2D 


2,16(32x67,5) 


4 


4,32 


1U 


0,945(14x67,5) 


16 


3,78 


US 


3,78 


3,378 


A4-01OAG-R1 
A4-01OBG-R1 


ID 


2,025 (30 x 67,5) 


256 


16,2 


DS 


26,8 


24,133 


2D 


2,16(32x67,5) 


32 


10,8 


1U 


0,945(14x67,5) 


16 


3,78 


US 


3,78 


3,378 


NOTE: Payload rate is calculated assuming single latency. 



Table 11 : Asymmetric Profiles - Optional Regional Specific Spectrum Allocation 



Profile code 


Carrier 


Carrier frequency 
fc (MHz) 


Lowest 
frequency 

^LOw(MHz) 


Highest 
frequency 
/high (MHz) 


PSD 
(dBm/Hz) 


A1-02OAG-R1 
A1-02OBG-R1 


ID 


2,26125(67x33,75) 


1,13 


3,4 


-61 


1U 


4,455(132x33,75) 


3,97 


4,94 


A2-02OAG-R1 
A2-02OBG-R1 


ID 


2,32875 (69 x 33,75) 


1,12 


3,54 


1U 


4,455(132x33,75) 


3,97 


4,94 


A3-01OAG-R1 
A3-01OBG-R1 


ID 


2,32875 (69 x 33,75) 


1,12 


3,54 


2D 


6,885 (204 X 33,75) 


5,59 


8,18 


1U 


4,5225(134x33,75) 


3,96 


5,09 


A4-01OAG-R1 
A4-01OBG-R1 


ID 


2,32875 (69 x 33,75) 


1,12 


3,54 


2D 


6,885 (204 X 33,75) 


5,59 


8,18 


1U 


4,5225(134x33,75) 


3,96 


5,09 



£75/ 



40 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



Table 12: Symmetric Profiles - Bit Rates 



Profile code 


Carrier 


Symbol Rate 

SR 

(MBaud) 


Consteli. 
C 


Data Rate 
DR 

(Mb/s) 


Total Rate 
TR 

(Mb/s) 


Maximum 

Payload Rate 

(Mb/s) 


S1-03OAG-R1 
S1-03OBG-R1 


ID 


1,89(28x67,5) 


16 


7,56 


DS 


7,56 


6,757 


1U 


0,945(14x67,5) 


32 


4,725 


US 


7,56 


6,757 


2U 


1,4175(21 x67,5) 


4 


2,835 


S2-03OAG-R1 
S2-03OBG-R1 


ID 


2,025 (30 X 67,5) 


32 


10,125 


DS 


10,125 


9,05 


1U 


0,945(14x67,5) 


32 


4,725 


US 


10,395 


9,291 


2U 


1,89(28x67,5) 


8 


5,67 


S3-00OAG-R1 
S3-00OBG-R1 


ID 


1,89(28x67,5) 


32 


9,45 


DS 


17,55 


15,687 


2D 


2,025 (30 X 67,5) 


16 


8,1 


1U 


1,08(16x67,5) 


32 


5,4 


US 


16,2 


14,48 


2U 


2,7(40x67,5) 


16 


10,8 


S4-00OAG-R1 
S4-00OBG-R1 


ID 


1,89(28x67,5) 


256 


15,12 


DS 


27,27 


24,375 


2D 


2,025 (30 X 67,5) 


64 


12,15 


1U 


1,08(16x67,5) 


512 


9,72 


US 


25,92 


23,168 


2U 


2,7(40x67,5) 


64 


16,2 


NOTE: Payload rate is calculated assuming single latency. 



Table 13: Symmetric Profiles - Optional Regional Specific Spectrum Allocation 



Profile Code 


Carrier 


Carrier frequency 
fc (MHz) 


Lowest 
frequency 

fLow(MHz) 


Highest 
frequency 
/high (MHz) 


PSD 
(dBm/Hz) 


S1-03OAG-R1 
S1-03OBG-R1 


ID 


2,26125(67x33,75) 


1,13 


3,4 


-61 


1U 


4,5225(134x33,75) 


3,95 


5,09 


2U 


10,125(300x33,75) 


9,27 


10,98 


S2-03OAG-R1 
S2-03OBG-R1 


ID 


2,32875 (69 x 33,75) 


1,12 


3,54 


1U 


4,5225(134x33,75) 


3,95 


5,09 


2U 


10,395(308x33,75) 


9,26 


11,53 


S3-00OAG-R1 
S3-00OBG-R1 


ID 


2,32875 (69 x 33,75) 


1,13 


3,4 


2D 


6,885 (204 x 33,75) 


5,67 


8,1 


1U 


4,5225(134x33,75) 


3,87 


5,17 


2U 


10,36125(307x33,75) 


8,74 


11,98 


S4-00OAG-R1 
S4-00OBG-R1 


ID 


2,26125(67x33,75) 


1,13 


3,4 


2D 


6,885 (204 x 33,75) 


5,67 


8,1 


1U 


4,5225(134x33,75) 


3,87 


5,17 


2U 


10,36125(307x33,75) 


8,74 


11,98 



6 Transmission Convergence (TC) layer 

The Transmission Convergence (TC) sub-layer provides adaptation of different applied transport protocols to the PMD 
by transformation of any applied protocol into a generic octet-oriented stream and mapping it into the transmission 
frame format generated by the PMS-TC sub-layer. 

6.1 TC layer functionality 
6.1 .1 Generic functional model 

The TC layer functional model, as presented in figure 25, defines the TPS-TC and PMS-TC sub-layers. The functional 
model is identical for the VTU-O and VTU-R except for the method of providing the Network Timing Reference 
(NTR). 

The TPS-TC sub-layer contains a number of TPS-TC blocks intended for different transport protocols. The main 
transport protocols are ATM, STM and PTM. A special TPS-TC block supports the Operation Channel (OC) including 
the clear eoc. 
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The TPS-TC signals are multiplexed into either the Delay-sensitive (Fast) or Delay-insensitive (Slow) channels 
corresponding to their latency requirements by two time division multiplexers: MUX_f and MUX_s, as shown in 
figure 25. Both the Fast and Slow multiplexed signals have an application independent format on the a(P)-interface. 

On the PMS-TC sub-layer both the Fast and Slow channels are randomised, protected by FEC and mapped into the 
transmission frame. The Slow channel protection includes interleaving. The transmission frame contains separate fields 
for Fast and Slow channels. The frame header carries frame alignment, OAM data and NTR markers. 

The Slow channel is mandatory, the Fast channel is optional. The system provides dual latency if both the Fast and 
Slow channels are implemented. If only the Slow channel is implemented, the system provides single latency. 

The particular data rates and payload allocations for each of the multiplexed TPS-TC at the a(P) reference point are 
asserted during the system configuration. The mandatory TC configuration shall provide one application transport 
protocol over the Slow channel. All other configurations are optional. 

The TC OAM entity is divided between TPS-TC Management (Path related functions) and PMS-TC Management (Line 
related functions). The exchange of management information with TPS-TC Management is accomplished via the 
y-interface; with PMS-TC Management it is accomplished via the a(P)-interface. 

The NTR 8 kHz network timing shall be transported to the customer unit via the VDSL link to support some specific 
services. The NTR timing marker is sent to the VTU-O TC across the a interface and delivered to the customer unit 
across the P interface at the VTU-R. The method of transporting the NTR is described in clause 6.L5. 



Internal Interfaces for different application transport protocols 



Y interface 




OAM 
Entity 



ot/p Interface 



I- Interface 
To PMD management 



NOTE 1 : At the VTU-O the downstream is transmitted and the upstream is received. At the VTU-R the downstream 

is received and the upstream is transmitted. 
NOTE 2: The set of TPS-TC blocl<s may be different in each transmission direction (dual latency downstream and 

single latency upstream, for instance). 
NOTE 3: If there is more than one application of the same type (two Fast STM, for instance), the corresponding 

multiplexing shall be done above the TC sub-layer. 
NOTE 4: The Fast and Slow channels meet different performance requirements because of the interleaving. 

Figure 25: TC Functional IVIodel 
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6.1.2 ATM transport 



6.1.2.1 



Functional model of ATM transport 



The TPS-TC sub-layer functional model of ATM transport derived from figure 25 is presented in figure 26. It contains 
two identical ATM TPS-TC blocks (ATM_TC), intended to support ATM transmission over the Fast (Delay-sensitive 
applications) and the Slow (Delay-insensitive applications) channels. The mandatory configuration shall include one 
ATM_TC (Slow, single-latency). For optional dual latency operation the second ATM_TC is required. 

The TPS-TC OAM block provides all necessary OAM functions to support both ATM_TC. 



o 

1- 

5 



ATM 
Layer 



Delay-Sensitive 
Services 



Fast Ciiannel 



Delay-insensitive 
Services 



ATM-TC 




Slow Ciiannel 



Y-interface 



OAM Entity 

A 



TPS-TC 
management 



a/p-interface 



To PMS-TC and PMD 



Figure 26: Functional IVIodel of ATIV! Transport 

The y-interface of both ATM_TC shall interface the ATM Layer as described in clause 6.2.1.1. Both the Fast and Slow 
ATM_TC have the same application independent format at the oc/p -interface. 



6.1.2.2 



Transport of ATM data 



To transport ATM data, the bit rates of both the upstream and downstream channels shall be set independently of each 
other to any of the eligible bit rates up to the maximum rate determined by the payload rate of the applied transmission 
profile and the applied transmission frame. Both are set during the system configuration. 

The channelisation of different user payloads into either the Fast or the Slow channel is embedded within the ATM data 
stream by using different Virtual Paths and/or Virtual Channels. To meet the basic requirements for ATM data 
transport, at least a single latency mode (in both downstream and upstream channel) shall be supported. 

The need for either a single or a dual latency for ATM transport depends on the type of service. One of the three 
"latency classes" may be used: 

• Latency Class 1: single latency both upstream and downstream (not necessarily the same for each direction of 
transmission) - mandatory. 

• Latency Class 2: dual latency downstream, single latency upstream - optional. 

• Latency Class 3: dual latency upstream and downstream - optional. 

NOTE: For single latency applications the Slow channel may be used to implement the Fast channel as well by 
changing of its interleaving depth. In particular, the interleaver may be disabled in the Slow channel by 
setting the interleaver depth to zero. 
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6.1.3 STM transport 

This clause specifies both PDH and SDH data transport. 



6.1.3.1 



Functional model of STM transport 



The TPS-TC sub-layer functional model of STM transport derived from figure 25 is presented in figure 27. It contains 
one STM TPS-TC block (STM_TC), intended to support SDH or PDH transmission over the Fast channel or the Slow 
channel. Any STM application uses only single latency. 



o 



o 



STM 
Layer 



STM-TC 



Fast or Slow Channel 



0AM Entity 



yinterface 



TPS-TC 
management 



o/g^interface 



To PMS-TC and PMD 



l-interface 



Figure 27: Functional IVIodel of STIVI Transport 

The TPS-TC OAM block provides all necessary OAM functions to support the STM_TC. 

NOTE 1 : STM services are usually delay-sensitive, hence the set interleaving depth of the Slow channel shall 
correspond to the applied service latency requirements. 

NOTE 2: If there are more than one STM application, some of them can be transmitted over the Fast channel and 
some over the Slow channel. In this case the system shall provide dual latency. 

The y-interface of STM_TC shall interface with the corresponding STM Layer as described in clause 6.2. The STM_TC 
has a standard application-independent format at the OC/P-interface as described in clauses 6.3 and 6.4. 



6.1.3.2 



Transport of STM data 



To transport STM data the same bit rates shall be applied in both the upstream and downstream channels (symmetric 
profiles only). The channel aggregate payload rate, which is determined by the applied transmission profile and the 
applied transmission frame, shall be higher than the rate of the applied STM transport. Both are set during the system 
configuration. 

The details of this section are for further study. 
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6.1 .4 Packets Transport Mode (PTM) 



6.1.4.1 



Functional Model of PTM transport 



The functional model of PTM transport is shown in figure 28. In the transmit direction, the PTM entity obtains data 
packets to be transported over VDSL from the application interface. The PTM entity processes each packet and sends it, 
depending on the latency requirement to the y-interface of either the Fast or Slow path intended for packetized data 
transport. The corresponding TPS-TC (PTM-TC) receives the packet from the y-interface, encapsulates it into the 
specific frame format (PTM-TC frame) and maps it into the PMS-TC frame (transmission frame) for transmission over 
the VDSL link. 



PTM Entity 



'^ Packets carrying '^ Packets carrying 



delay-sensitive 
services 



delay-insensitive 
services 



OAM Entity 
y-interface A 




a/p- interface 



To PMS-TC and PMD 



I - interface 



Figure 28: Functional model of PTM transport 

In the receive direction, the PTM-TC frame extracted from the received PMS-TC frame is sent to the PTM-TC. The 
PTM-TC recovers the transported packet and delivers it to the PTM entity via the y-interface. 

The PTM path-related OAM data, including information on errored packets, shall be presented to the TPS-TC 
management entity providing all necessary OAM functions to support both PTM-TC. 

The y-interfaces of both PTM-TC are identical and described in clause 6.2.4. The oc/P-interfaces are application 
independent and are described in clause 6.3.2.1. 



6.1.4.2 



Transport of PTM Data 



The bit rate of PTM data transport in the upstream and downstream directions may be set independently to any eligible 
value which is less than the assigned maximum bit rate in the corresponding direction. Both the upstream and 
downstream maximum bit rates for PTM transport are set during the system configuration. 

The PTM transport can use either the Slow channel or Fast channel or both. The PTM-TC for either channel has the 
same characteristics. The packet transport shall include at least one PTM-TC (either Fast or Slow). The second 
PTM-TC is optional. 

If PTM is the only transport established over the VDSL link, the Slow channel shall be used in accordance with the 
generic TPS-TC sublayer architecture. The required latency shall be obtained by adjustment of the interleaving depth. 
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The PTM-TC shall provide transparent data transfer between the Jq and yj^ interfaces (except non-correctable errors in 
the PMD sublayer due to the noise in the loop). The PTM-TC shall provide packet integrity and packet error monitoring 
over either the Fast or Slow channels. 

6.1 .5 Network timing reference transport 

The Network Timing Reference (NTR) timing marker is mapped into the transmission frame at the VTU-O, extracted in 
the PMS-TC of the VTU-R and delivered to the customer unit across the P interface (clauses 6.4.4.4.4 and 6.5.1.3.6). 

6.2 Transport Protocol Specific TC (TPS-TC) sub-layer 

6.2.1 ATIVI Transport Protocol Specific TC (ATM_TC) 
6.2.1.1 Application interface description 

The ATM_TC application interface (figure 26) is specified at both the Y_0 and Y_R reference points of the VTU-O and 
VTU-R respectively. Both y-interfaces are functional, identical and shall be defined by the following flows of signals: 

• data flow; 

• synchronisation flow; 

• control flow; 

• OAM flow. 

NOTE 1 : If dual latency is supported, the y-interface comprises two identical flows of signals - each belongs to the 
corresponding ATM_TC. 

NOTE 2: For a dual latency implementation ATM cell de-multiplexing to (multiplexing from) the appropriate 
ATM_TC (of the Fast or the Slow channel) shall be performed at the ATM layer based on the Virtual 
Path Identifier (VPI) and Virtual Channel Identifier (VCI), both contained in the ATM cell header. 

6.2.1.1.1 Dataflow 

The data flow consists of two streams of 53-octet ATM cells each (Tx_ATM, Rx_ATM) with independent rates flowing 
in opposite directions. Rate values are arbitrary under a pre-defined upper limit of channel aggregate transport 
capability, determined by the data rate at the a(P) interface. The data flow signal description is presented in table 14. 

The ATM cell format is identical in transmit and receive directions. Octet number 5 is undefined and is reserved for 
HEC insertion in the TC layer. 

NOTE 1 : If data streams are serial by implementation, the MSB of each octet is sent first. 

NOTE 2: The data flow signals are amenable to UTOPIA interface implementation as shown in annex A. 
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6.2.1.1.2 



Synchronisation flow 



This flow provides synchronisation between the ATM layer and the ATM_TC. It includes both the ATM data 
synchronisation signals and the NTR signal. 

The synchronisation flow comprises the following signals, presented in table 14: 

transmit and receive timing signals (Tx_Clk, Rx_Clk) are both asserted by the ATM layer; 

Start-of-Cell marker (TxSOC, RxSOC), a bi-directional signal intended to identify the beginning of the 
transported cell in the corresponding direction; 

Transmit Cell Available flag (TxClAv), asserted by ATM TPS-TC to indicate that ATM TPS-TC is ready to 
get a received cell from the ATM layer; 

Receive Cell Available flag (RxClAv), asserted by ATM TPS-TC to indicate that TPS-TC contains a valid cell 
and is ready to transmit it towards ATM layer; 

Transmit Timing Reference (TxRef), applied only at the VTU-O, and coming from the network 8 kHz NTR; 

Receive Timing Reference (RxRef), is an 8 kHz NTR recovered from the received VDSL signal at the 
VTU-R. 

NOTE 1 : The Tx_Clk and the Rx_Clk rates are matched to the Tx_ATM and the Rx_ATM data rates respectively. 

NOTE 2: NTR signal has opposite directions at the VTU-O and the VTU-R. 

NOTE 3: The synchronisation flow signals can be implemented using a UTOPIA interface as shown in annex A. 



6.2.1.1.3 



Control flow 



Two control signals are used to provide multiple ATM_TC connection to the ATM layer. Both are asserted by the ATM 
layer: 

• Transmit Enable signal (Enbl_Tx) indicates to the ATM_TC that the next transmitted Tx_ATM cell is valid; 

• Receive Enable signal (Enbl_Rx) allows the ATM_TC to transmit a Rx_ATM cell towards the ATM layer. 
NOTE: The control flow signals are amenable to UTOPIA interface implementation as shown in annex A. 

Table 14: ATM-TC: T^interface Data, Synchronisation and Control Flow Signal Summary 



Flow 


Signal 


Description 


Direction 


Notes 






Transmit signals 






Data 


Tx_ATM 


Transmit cell 


ATM ^TPS-TC 




Sync 


Tx_Clk 


Transmit timing 


ATM -^ TPS-TC 




Sync 


TxSOC 


Start of the transmit cell 


ATM -^ TPS-TC 




Sync 


TxClAv 


TPS-TC is ready to get a cell 


ATM ^ TPS-TC 




Control 


Enbl_Tx 


TPS-TC polling for an incoming cell 


ATM -^ TPS-TC 




NTR 


TxRef 


8 kHz NTR 


VTU-O -^ TPS-TC 


Vl_0 only 






Receive signals 






Data 


Rx_ATM 


Receive cell 


ATM ^ TPS-TC 




Sync 


Rx_Clk 


Receive timing 


ATM -^ TPS-TC 




Sync 


RxSOC 


Start of the receive cell 


ATM ^ TPS-TC 




Sync 


RxClAv 


TPS-TC is ready to transmit a cell 


ATM ^ TPS-TC 




Control 


Enb_Rx 


TPS-TC polling for the outgoing cell 


ATM -^ TPS-TC 




NTR 


RxRef 


8 kHz NTR 


VTU-R ^ TPS-TC 


VI_R only 
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6.2.1.1.4 0AM flow 



The OAM Flow across the y-interface exchanges OAM information between the VTU OAM entity and its 
ATM_TC-related part of TPS-TC management functions. OAM flow is bi-directional and transports ATM path-related 
primitives, parameters and maintenance signals/commands described in clauses 7.3.2.1 and 7.3.5.3.1. 

6.2.1 .2 ATM_TC functionality 

The following ATM_TC functionality shall be applied in both the downstream and upstream transmission directions. 

6.2.1 .2.1 Cell rate de-coupling 

The cell rate de-coupling shall be implemented by insertion of Idle cells in the transmit direction and deletion of Idle 
cells in the receive direction (at the remote ATM_TC), as specified in ITU-T Recommendation 1.432.1 [2]. A standard 
cell header shall identify Idle cells as specified in ITU-T Recommendation 1.432.1 [2]. 

6.2.1 .2.2 HEC generation and verification 

The HEC byte shall be generated as described in ITU-T Recommendation 1.432 [3], including the recommended 
modulo-2 addition (XOR) of the pattern 01010101b to the HEC bits. The generator polynomial coefficient set used and 
the HEC sequence generation procedure shall be in accordance with ITU-T Recommendation 1.432 [3]. 

The HEC sequence shall be capable of multiple-bit error detection, as defined in ITU-T Recommendation 1.432 [2]. The 
single-bit error correction of the cell header shall not be performed. 

6.2.1 .2.3 Cell payload randomisation and de-randomisation 

Randomisation of the transmit ATM cell payload avoids continuous non-variable bit patterns in the ATM cell stream 
and so improves the efficiency of the cell delineation algorithm. 

The ATM cell randomiser shall use a self-synchronising scrambler polynomial x*^^ + 1 . The randomisation procedure 
shall be as defined in ITU-T Recommendation 1.432 [3] for SDH-based transmission. The corresponding 
de-randomisation process shall be implemented by the remote ATM_TC. 
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6.2.1.2.4 



Cell delineation 



The cell delineation function permits the identification of ATM cell boundaries in the payload. It is based on a coding 
law using the Header Error Control (HEC) field in the cell header. 

The cell delineation algorithm shall be implemented as described in ITU-T Recommendation 1.432 [3]. It includes the 
following states and state transitions, presented in figure 29: 

• "HUNT" to "PRESYNC" state transition when HEC coding law is confirmed once. 

• "PRESYNC" to "SYNC" state transition when HEC coding law is confirmed a = 5 times consequently; 

• "SYNC" to "HUNT" state transition when HEC coding law is violated 5 = 7 times consecutively. 



CodingLawViolated 
at expected positions 




CodingLawConfirmed 




5 consecutive 
CodingLawViolated 
at expected positions 



a consecutive 

CodingLawConfirmed 

at expected positions 




Figure 29: ATM Cell Delineation State IVIachine 



6.2.2 SDH Transport Protocol Specific TC (SDH_TC) 



6.2.2.1 



Application interface description 



The SDH_TC application interface is specified at both the Y_0 and Y_R reference points of the VTU-O and VTU-R 
sites respectively, as shown in figure 27. Both y-interfaces are functional, identical and shall be defined by the following 
flows of signals: 

• data flow; 

• synchronisation flow; 

• OAM flow. 



6.2.2.1.1 

For further study. 

6.2.2.1.2 

For further study. 

6.2.2.1.3 

For further study. 



Data flow 



Synchronisation flow 



OAM flow 
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6.2.2.2 SDH TPS-TC functionality 

For further study. 

6.2.3 Overhead channel TPS-TC (OC_TC) 



6.2.3.1 



Application interface description 



The OC_TC appHcation interface is specified at both the y_0 and Y_R reference points of the VTU-O and VTU-R sites 
respectively, as shown in figure 25. Both y-interfaces are functionally identical and shall be defined by the following 
flows of signals: 



• data flow; 

• synchronisation flow. 



6.2.3.1.1 



Data flow 



The data flow includes two streams of 2-octet messages (eoc messages; Tx_eoc, Rx_eoc) with independent rates 
flowing in opposite directions. Rate values are arbitrary under a pre-defined upper limit of the OC aggregate transport 
capability. The data flow signal description is presented in table 15. 

NOTE: If data streams are serial by implementation, the MSB of each octet is sent first. 



6.2.3.1.2 



Synchronisation flow 



This flow provides synchronisation between the VDSL Management Entity (VME) serving as the eoc application layer 
(figure 48) and the OC_TC. It includes the following synchronisation signals, presented in table 15: 

• transmit and receive timing signals (eoc_tx_clk, eoc_rx_clk): both asserted by the eoc processor; 

• transmit enable flag (tx_enbl): asserted by OC_TC and allows transmission of the next 2-octet message; 

• receive enable flag (rx_enbl): asserted by OC_TC and indicates that the next 2-octet message is allocated in 
the OC_TC receive buffer. 

Table 15: OC_TC: y-interface Data and Synchronisation Flow Summary 



Signal 



Description 



Direction 



Notes 



Data flow 



eoc tx 



Transmit eoc data 



VME ^ OC-TC 



Two octet message 



eoc rx 



Receive eoc data 



VIVIE ^ OC-TC 



Synchronisation flow 



eoc tx elk 



Transmit clock 



VIVIE ^ OC-TC 



eoc rx elk 



Receive clock 



VIVIE -^ OC-TC 



tx enbl 



Transmit enable flag 



VME ^ OC-TC 



Active if the transmit OPCODE = IDLE 



rx enbl 



Receive enable flag 



VME ^ OC-TC 



Active if the received OPCODE = IDLE 



NOTE: All the buffering required to implement the eoc communication protocol should be provided by the 
VME; no buffering for eoc is expected in the OC-TC. 



6.2.3.2 Single Carrier OC_TC functionality 

The following OC_TC functionality shall be applied in both the downstream and upstream transmission directions. 
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6.2.3.2.1 VOC and eoc multiplexing 

The VOC and eoc multiplexing/de-multiplexing is based on the appHed OC channel OPCODE value (clause 6.5.1) 
which distinguishes the OC field contents. The VOC shall get priority in the multiplexing process: if both a VOC and 
eoc messages are ready to be sent, the VOC message shall be sent first. 

When no VOC message is to be sent in the given Slow codeword, the OC OPCODE octet of this codeword shall be set 
to either OxFF or OxFC ("IDLE" message OC OPCODE or "EOC" message OC OPCODE, clause 7.5.3.1). In the IDLE 
message 0x0000 shall be inserted into the OC DATA field. In the EOC message the next two octets of the eoc message 
shall be inserted into the OC DATA field. When a VOC message other than IDLE has to be sent eoc transparency shall 
be interrupted and the relevant VOC OPCODE (clause 7.5.3) shall be used. When the VOC message transmission is 
complete, the OPCODE value shall be set to IDLE. After the specified number of IDLE messages have been sent 
(clause 7.5.2), eoc transport over the OC may be resumed. 

6.2.3.2.2 De-multiplexing 

If the received OC OPCODE equals OxFC, the contents of the OC DATA field shall be output to the VME via the 
Y-interface. The OC OPCODE OxFF indicates that no OC data is transferred (IDLE). If the received OC OPCODE is 
equal to any other value (not OxFF, nor OxFC), the received OC DATA field shall be processed as a possible valid VOC 
OPCODE (clause 7.5.3) by the VOC processor. 

NOTE: The OC OPCODE OxFC indicates that the received OC DATA octets may contain an eoc message. The 
eoc processor will identify valid messages as described in clause 7.6.3). 

6.2.4 PTM transport protocol specific TC (PTM-TC) 
6.2.4.1 Application Interface Description 

The Yo and Yr reference points define interfaces between the PTM entity and PTM-TC at the VTU-O and VTU-R 
respectively as shown in figure 28. Both interfaces are identical, functional, and independent of the contents of the 
transported packets. The interfaces are defined by the following flows of signals between the PTM entity and the 
PTM-TC sublayer: 

• Data flow; 

• Synchronization flow; 

• Control flow; 

• OAM flow. 
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6.2.4.1.1 



Data Flow 



The data flow shall consist of two contra-directional octet-based streams of packets: transmit packets (Tx_PTM) and 
receive packets (Rx_PTM). The packet transported in either direction over the y-interface may be of variable length. 
Bits within an octet are labeled ai through og, with a\ being the LSB and a^ being the MSB. If either of data streams is 
transmitted serially, the first octet of the packet shall be transmitted first and bit ai of each octet shall be transmitted 
first as shown in figure 30. The Data Flow signal description is presented in table 16. 

Table 16: PTM -TC T^interface Data, Syncronization and Control Flows Signal Summary 



Flow Signal Description Direction 


Transmit signals 


Data 


Tx PTM 


Transmit data 


PTM ^ PTM-TC 


Control 


Tx_Enbl 


Asserted by the PTM-TC; indicates PTIVI may push data to 
the PTM-TC 


PTM <- PTM-TC 


Control 


TX Err 


Errored transmit packet (request to abort) 


PTM ^ PTM-TC 


Sync 


Tx_Avbl 


Asserted by the PTM entity if data is available for 
transmission 


PTM ^ PTM-TC 


Sync 


Tx Clk 


Clock signal asserted by the PTM entity 


PTM ^ PTM-TC 


Sync 


Tx SoP 


Start of the transmit Packet 


PTM -^ PTM-TC 


Sync 


Tx EoP 


End of the transmit Packet 


PTM -> PTM-TC 


Receive signals 


Data 


Rx PTM 


Receive data 


PTM «- PTM-TC 


Control 


Rx_Enbl 


Asserted by the PTM-TC; indicates PTM may pull data from 
the PTM-TC 


PTM <- PTM-TC 


Control 


RX_Err 


Received error signals including PCS error, Invalid Frame, 
and OK 


PTM <- PTM-TC 


Sync 


Rx Cll< 


Clock signal asserted by the PTM entity 


PTM -> PTM-TC 


Sync 


Rx SoP 


Start of the receive Packet 


PTM <- PTM-TC 


Sync 


Rx EoP 


End of the receive Packet 


PTM <r PTM-TC 



6.2.4.1.2 



Synchronization Flow 



This flow provides synchronization between the PTM entity and the PTM-TC sublayer and contains the necessary 
timing to provide packet integrity during the transport. The synchronization flow shall consist of the following signals 
presented is presented in table 16. 

• Transmit and receive timing signals (Tx_Clk, Rx_Clk); both asserted by PTM entity. 

• Start of Packet signals (Tx_SoP, Rx_SoP): asserted by PTM entity and by PTM-TC respectively and intended 
to identify the beginning of the transported packet in the corresponding direction of transmission. 

• End of Packet signals (Tx_EoP, Rx_EoP): asserted by PTM entity and by PTM-TC respectively and intended 
to identify the end of the transported packet in the corresponding direction of transmission. 

• Transmit Packet Available signals (Tx_Avbl): asserted by PTM entity to indicate that data for transmission in 
the corresponding direction is ready. 



6.2.4.1.3 



Control Flow 



Control signals are used to improve robustness of data transport between the PTM-entity and PTM-TC and are 
presented in table 16. 

• Enable signals (Tx_Enbl, Rx_Enbl): asserted by PTM-TC and indicates that data may be respectively send 
from PTM entity to PTM-TC or pulled from PTM-TC to PTM entity. 

• Transmit error message (Tx_Err): asserted by the PTM entity and indicates that the packet or a part of the 
packet already transported from PTM entity to PTM-TC is errored or undesirable for transmission (abort of 
transmitted packet). 

• Receive error message (Rx_Err): shall be asserted by the PTM-TC to indicate that an errored packet is 
transported from PTM-TC to PTM entity. 
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Handling of packet errors is described in clause 6.2.4.2.5. 

6.2.4.1.4 0AM Flow 

The OAM Flow across the y-interface exchanges OAM information between the OAM entity and its PTM related 
TPS-TC management functions. The OAM flow is bi-directional. 

The OAM flow primitives are for further study. 

6.2.4.2 PTM TPS-TC Functionality 

The following PTM TPS-TC functionality should be applied both to the downstream and upstream transmission 
directions. 

6.2.4.2.1 Packet encapsulation 

For packet encapsulation an HDLC-type mechanism shall be used with detailed characteristics as specified in the 
following subsections. 

6.2.4.2.2 Frame structure 

The PMS-TC frame format shall be as shown in figure 30. The opening and closing Flag Sequences which identify the 
start and the end of each frame shall be set to 0x7E. Only one Flag Sequence is required between two consecutive 
frames. 

8 7 6 5 4 3 2 1 Bits 

0x7E Opening Flag Sequence 

Default = OxFF Address field 

Default = 0x03 Control field 



Information field 



Data 



FCS-1 First octet of FCS 

FCS-2 Second octet of FCS 

0x7E Closing Flag Sequence 



Figure 30: PTM-TC frame format 

The Address and Control octets are intended for auxiliary information. They shall be set to their default values of OxFF 
and 0x03 respectively if not used. 

NOTE 1 : The address and Control fields may be used for different auxiliary OAM functions. The usage of these 
fields is for further study. 

The Information field shall be filled with the transported data packet. Prior to encapsulation the octets of the data packet 
shall be numbered sequentially. Octets shall be transmitted in ascending numerical order. 

The Frame Check Sequence (FCS) octets are used for packet level error monitoring, and shall be set as described in 
clause 6.2.4.2.4. 

After encapsulation, bits within an octet are labeled b^ through b^, as defined in figure 31. If the a(P) interface is serial 
by implementation, bit b^ of each octet shall be transmitted first. 
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NOTE 2: In keeping with the labelling convention for the a(P) interface, bit b^ (MSB) is transmitted first. The 

PTM-TC functionality defines a correspondence between ai and b^, aj and bj, etc., in order to conform to 
the HDLC convention of transmitting bit Oi first. 



Octet # 
Data-1 
Data-2 

I 

I 

Data-N 



Flag 

OxFF 

0x03 

Data-1 

Data-2 

I 

I 

Data-N 

FCS-1 

FCS-2 

Flag 



as 


ai 


at, 


as 


at 


a3 


ai 


a, 


MSB 














LSB 





A 



V 



fol 


bi 


hi 


b4 


bs 


be. 


bi 


h. 





1 


1 


1 


1 


1 


1 





1 


1 


1 


1 


1 


1 


1 


1 




















1 


1 


ag 














a. 







MSB 

FCS 


LSB 

FCS 





1 


1 


1 


1 


1 


1 






A 



7 - interface ^i transniitted 

' first 



HDLC 

Encapsulation 



first 



a(P) - interface's transmitted 



V 

Figure 31 : PTM-TC data flow 



6.2.4.2.3 



Octet transparency 



To prevent false frame synchronisation, any octet inside the PTM-TC frame that is equal to 0x7E (the Flag Sequence) 
or 0x7D (the Control Escape) shall be escaped as described below. 

After the Frame Check Sequence has been calculated, the transmitter shall examine the entire frame between the 
opening and the closing Flag Sequences. Any data octets whose value equals the Flag Sequence or the Control Escape 
shall be replaced by a two-octet sequence consisting of the Control Escape octet followed by the original octet 
exclusive-OR'ed with 0x20. In summary, the following substitutions shall be made: 

• any data octet equal to 0x7E shall be encoded as a two octet sequence 0x7D, Ox5E; 

• any data octet equal to 0x7D shall be encoded as a two octet sequence 0x7D, Ox5D. 

On reception, prior to Frame Check Sequence calculation, each Control Escape octet shall be removed, and the 
following octet shall be exclusive-OR'ed with 0x20 (unless the following octet is 0x7E (Flag Sequence) which indicates 
that the transmission of current frame has been aborted). In summary, the following substitutions are made: 

• any sequence of 0x7D, Ox5E shall be replaced by the data octet 0x7E; 

• any sequence of 0x7D, Ox5D shall be replaced by the data octet 0x7D; 

• a sequence of 0x7D, 0x7E shall indicate the end of an aborted frame. 

NOTE: Since octet stuffing is used, the PMT-TC frame is guaranteed to have an integer number of octets. 
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6.2.4.2.4 Frame Check Sequence (FCS) 

The FCS shall be calculated over all bits of the address, control, and information fields of the PTM-TC frame as defined 
in ISO/IEC 13239, i.e. it shall be the one's complement of the sum (modulo 2) of: 

• the remainder ofx^(x^^+x^'^+x^^+x^^+x^^+x^^+x^+x^+x^+x^+x^+x'^+x^+x^+x+l) divided (modulo 2) by the 
generator polynomial x^^+x^^+x^+l, where k is the number of bits in the frame existing between, but not 
including, the last bit of the opening flag and the first bit of the FCS, excluding octets inserted for transparency 
(clause 6.2.4.2.3); 

and 

• the remainder of the division (modulo 2) by the generator polynomial x'^+x'^+x^+1, of the product of x^^ by 
the content of the frame existing between, but not including, the last bit of the opening flag and the first bit of 
the FCS, excluding octets inserted for transparency. 

The FCS is 16 bits (2 octets) in length and occupies fields FCS-1 and FCS-2 of the PTM-TC frame. The FCS shall be 
mapped into the frame so that bit oi (b^) of FCS-1 shall be the MSB of the calculated FCS, and bit ag (^i) of the FCS-2 
shall be the LSB of the calculated FCS (flgure 31). 

The register used to calculate the FCS at the transmitter shall be initialized to the value FFFFig. 

NOTE: As a typical implementation at the transmitter, the initial content of the register of the device computing 
the remainder of the division is preset to all binary ONEs and is then modified by division by the 
generator polynomial, as described above, on the information field. The one's complement of the resulting 
remainder is transmitted as the 16-bit FCS. 

As a typical implementation at the receiver, the initial content of the register of the device computing the 
remainder of the division is preset to all binary ONEs. The final remainder, after multiplication by x^^ 
and then division (modulo 2) by the generator polynomial x^^h-x'^h-x^h-1 of the serial incoming protected 
bits after removal of the transparency octets and the FCS, will be 0001 1 10100001 1 1 12 (x^^ through x*^, 
respectively) in the absence of transmission errors. 

6.2.4.2.5 Packet error monitoring 

Packet error monitoring includes detection of invalid and errored frames at the receive side. 

6.2.4.2.5.1 Invalid frames 

The following conditions result in an invalid frame: 

• Frames which are less than 4 octets long between the flags not including transparency octets (Flag Sequence 
and Control Escape). These frames shall be discarded; 

• Frames which contain a Control Escape octet followed immediately by a flag (i.e. 0x7D followed by 0x7E). 
These frames shall be passed across the y-interface to the PTM entity; 

• Frames which contain control escape sequences other than 0x7D, Ox5E or 0x7D, Ox5D. These frames shall be 
passed across the y-interface to the PTM entity. 

All invalid frames shall not be counted as FCS errors. The receiver shall immediately start looking for the opening flag 
of a subsequent frame upon detection of an invalid frame. A corresponding receive error message (Rx_Err) shall be sent 
across the y-interface to the PTM entity. 

6.2.4.2.5.2 Errored frames 

A received frame shall be qualified as an errored frame (FCS -errored) if the CRC calculation result for this frame is 
different from the described in clause 6.2.4.2.4. Errored frames shall be passed across the y-interface. A corresponding 
receive error message (Rx_Err) shall be sent across the y-interface to the PTM entity. 
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6.2.4.3 



Data rate decoupling 



Data rate decoupling is accomplished by filling the time gaps between transmitted PTM-TC frames with additional Flag 
Sequences (0x7E). Additional Flag Sequences shall be inserted at the transmit side between the closing Flag Sequence 
of the last transmitted PTM-TC frame and the subsequent opening Flag Sequence of the next PTM-TC frame, and 
discarded at the receive side respectively. 



6.2.4.4 



Frame delineation 



The PTM-TC frames shall be delineated by detecting Flag Sequences. The incoming stream is examined on an 
octet-by-octet basis for the value 0x7E. Two (or more) consecutive Flag Sequences constitute an empty frame (frames), 
which shall be discarded, and not counted as a FCS error. 

6.3 Physical Medium-Specific TC (PIVIS-TC) sub-layer 
6.3.1 Functional model 

The PMS-TC sub-layer functional model for both VTU-O and VTU-R is presented in figure 32. The PMS-TC sub-layer 
includes functional blocks for randomisation/de-randomisation (Scrambler), Forward Error Correction (FEC), 
interleaving, transmission frame encapsulation (MUX) and management. 

Both Fast and Slow channels have an application independent format at a(P)-interface. The transmission frame is 
multiplexed from the Slow and Fast data and a header. The header is combined from NTR markers. Indicator Bits (IB) 
special flags for VDSL link activation and a SyncWord for transmission frame alignment. The formatted transmission 
frame is output via the I-interface towards the PMD layer. 

The management block provides all OAM functions corresponding with PMS-TC (clause 7.2). 
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Scrambler 
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a/p-interface 
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MUX 



Transmission Frame 



To PMD management 



Figure 32: PMS-TC functional model 

The data incoming from a(P)-interface of both the Fast and Slow channels is randomised, protected by FEC and 
multiplexed into the transmission frame. The Slow channel error protection includes interleaving. The Fast channel is 
optional. If both Fast and Slow channels are implemented, the PMS-TC provides dual latency. The latency due to the 
interleaver can be different in the downstream and upstream transmission directions. 

The number of data channels, their transport capability and transmission frame format at the I_0 (I_R) reference point 
are defined by the transmission frame Transport Class and asserted during the system configuration. 
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6.3.2 Interface specification 
6.3.2.1 a(|3) - Interface 

The a and P reference points define interfaces between the TPS-TC and PMS-TC in the VTU-O and VTU-R 
respectively (figure 32). The interfaces are functional, application-independent and identical, excepting the direction of 
the NTR signals. Both interfaces are defined by the following signal flows: 

• data flow; 

• synchronisation flow; 

• OAM flow. 

6.3.2.1.1 Dataflow 

The data flow comprises of up to four generic octet-oriented asymmetric streams with bit rates defined by the PMD 
transmission capabilities: 

• two transmit data streams: Slow (Tx_s), Fast (Tx_f); 

• two receive data streams: Slow (Rx_s), Fast (Rx_f). 

The streams Tx_s and Rx_s are mandatory, Tx_f and Rx_f are optional. The Data flow signal description is summarised 
in table 17. 

NOTE 1 : If data streams are serial by implementation, the MSB of each octet is sent first. 

NOTE 2: The Tx_, Rx_ bit rate values are set during the system configuration. 

6.3.2.1.2 Synchronisation flow 

The synchronisation flow comprises of up to eight synchronisation signals: 

• transmit and receive data flow bit-synchronisation (Clk_t, Clk_r, respectively); 

• transmit and receive data flow octet-synchronisation (Osync_t, Osync_r, respectively); 

• transmit and receive data flow frame-synchronisation (Fsync_t, Fsync_r, respectively); 

• transmit or receive NTR marker (NTR_t, NTR_r, respectively). 

All synchronisation signals, except NTR_t, are asserted by PMS-TC and directed towards TPS-TC; NTR-t is directed 
towards TPS-TC. 

Signals Osync_t, Osync_r are mandatory, other signals are optional. The synchronisation flow signal description is 
summarised in table 17. 
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Table 17: a(|3)-lnterface Signal Summary 



Signal(s) 


Description 


Direction 


Notes 


Data Signals 


Tx s 


Transmit data, Slow 


TPS-TC - 


4 PMS-TC 


lUlandatory 


Tx f 


Transmit data, Fast 


Optional 


Rx s 


Receive data, Slow 


TPS-TC <r 


- PMS-TC 


lUlandatory 


Rx f 


Receive data. Fast 


Optional 


Synchronisation Signals 


Clk t 


Transmit bit timing 


TPS-TC <r 


- PMS-TC 


Optional 


Osync t 


Transmit octet timing 


lUlandatory 


Fsync t 


Transmit frame timing 


Optional 


Clk r 


Receive bit timing 


Optional 


Osync r 


Receive octet timing 


IVIandatory 


Fsync r 


Receive frame timing 


Optional 


NTR t 


Transmit NTR 


TPS-TC - 


4 PMS-TC 


Optional, VTU-0 only 


NTR_r 


Receive NTR 


TPS-TC ^ 


- PMS-TC 


Optional, VTU-R only 



6.3.2.1.3 



0AM flow 



The QAM Flow across the a((3) interface exchanges QAM information between the VTU- GAM entity, PMS-TC and 
PMD. QAM flow is bi-directional and transports line related primitives, parameters, configuration setup and 
maintenance signals/commands as specified in clauses 7.3.1, 7.3.3, 7.3.5.2 and 7.3.6. 



6.3.2.2 



l-lnterface 



The I_0 and I_R reference points define interfaces between the PMS-TC and PMD in the VTU-O and VTU-R 
respectively (figure 32). The interfaces are application independent and identical. Both interfaces are defined by the 
following signal flows: 

• data flow; 

• synchronisation flow. 

6.3.2.2.1 Dataflow 

The Data flow consists of two octet-oriented asymmetric streams, both formatted by a transmission frame with the bit 
rates defined by the applied PMD transmission profile: 

• transmit data (Tx); 

• receive data (Rx). 

The Data flow signal description is summarised in table 18. 

NOTE 1 : If data streams are serial by implementation, the MSB of each octet is sent first. 
NOTE 2: Each stream bit rate value is set during the PMD configuration. 
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6.3.2.2.2 



Synchronisation flow 



The synchronisation flow consists of the transmit and receive data flow bit-synchronisation signals (Clkp_t, Clkp_r) 
and the frame- synchronisation signals (Fsync_t, Fsync_r). Both signals are asserted by the PMD and directed towards 
the PMS-TC. The Synchronisation flow signal description is summarised in table 18. 

Table 18: l-interface signal summary 



Signal(s) 



Tx 



Rx 



Fsync_t 



Fsync_r 



Clkp_t 



Clkp_r 



Description 



Data Signals 



Transmit data stream 



Receive data stream 



Synchronisation Signals 



Transmit frame timing 



Receive frame timing 



Transmit bit timing 



Receive bit timing 



Direction 



PIVIS-TC -^ PMD 



PIVIS-TC ^ PIVID 



PIVIS-TC -^ PMD 



PMS-TC^ PMD 



PMS-TC^ PMD 



PMS-TC^ PMD 



Notes 



Transmission 
frame format 



6.4 



PMS-TC functions for multi-carrier modulation 



All data octets shall be transmitted MSB first. However, all serial processing (such as scrambling and CRC calculation) 
shall be performed LSB first, with the payload MSB considered as the LSB within the PMS-TC. As a result the first bit 
processed by the PMS-TC will be the MSB of the first payload octet. 
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Figure 33: PMS-TC block diagram 
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6.4.1 Scrambler 

A scrambler shall be used to reduce the likelihood that a long sequence of zeros will be transmitted over the channel. 
The scrambler shall be self-synchronising so that descrambling can occur without requiring a particular alignment with 
the scrambled sequence. The scrambler is represented by the equation below where m(n) is a message bit at time n and 
the output of the scrambler is x(n): 

x(n) = m(n) + x(n - 18) + x{n - 23), 

all arithmetic is modulo 2. As long as the scrambler is initialised with values other than zero, an "all zeros" sequence for 
m(n) will result in a pseudo random sequence of length 2^-' - 1 . At the input to the scrambler, the LSB of each octet 
enters the scrambler first. At the output of the scrambler, the LSB of each octet leaves the scrambler first. 

6.4.2 Forward error correction 

A standard octet-oriented Reed-Solomon code shall be used to provide protection against random and burst errors. 
Comprised of R redundant check octets co, cj, ...,0^.2, cr.j appended to /T message octets mo, nij, ...,m^.2, nix-i, a 
Reed-Solomon code word contains N=K+R octets. The check octets are computed from the message octets using the 
equation: 

C(D) = M(D)D'' modG(D) , 

where 

MiD) = m^^D''-'®mp''-^®...®mj^_^D®m^_, 
is the message polynomial. 



C{D) = c,,D''~'®c,D''-^®...®c^_^D®c^_ 



is the check polynomial, and G(D) = I I (D ® (X') is the generator polynomial of the Reed-Solomon code, where 

the index of the product runs from i = to /?-! . That is, C(D) is the remainder obtained from dividing M (D)D by 
G(D). The arithmetic is performed in the Galois Field GF(256), where a is a primitive element that satisfies the 
primitive binary polynomial X ® X ® X ® X ©l.A data octet (c/7, d(„ ..., dudo) is identified with the Galois Field 
element d-^a^ ® d^a^ ® ...® d^a® d^. 

Both K and R are programmable parameters. Redundancy values of R = 0, 2, 4, 6, 8 ... 16 shall be supported. The 
following code word parameters specified as (N,K) shall be supported: ( 144, 128) and (240, 224). Other values for A^ and 
K are optional. However, A^ shall be less than or equal to 255. 

6.4.3 Interleaving 
6.4.3.1 General 

Interleaving shall be used to protect the data against bursts of errors by spreading the errors over a number of 
Reed-Solomon codewords. The interleaver and de-interleaver shall be adjustable via the management system to meet 
latency requirements. The latency of the slow path is a function of the data rate and burst error correction capability. For 
data rates greater than or equal to 13 Mbps, the latency between the a and (3 interfaces shall not exceed 10 ms when the 
interleaver delay is set to the maximum. At lower data rates there is a trade-off between higher latency and decreased 
burst error correction ability. At any data rate, the minimum latency occurs when the interleaver is turned off. 

When the interleaver is on, the codewords shall be interleaved before transmission to increase the immunity of RS 
codewords to bursts of errors. The convolutional interleaver is defined by two parameters: the interleaver block length, 
/, and the interleaving depth, D. The block length / divides the RS codeword length N. The convolutional interleaver 
uses a memory in which a block of / octets is written while an (interleaved) block of / octets is read. 
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The convolutional interleaver introduces a read-to-write delay, A^ , that increments Hnearly with the octet index within 
a block of I octets: 



A^ =(D-1)X J, where; = 0, 1,2, . ..,/-!. 



6.4.3.2 



Triangular implementation 



To decrease the implementation complexity, the delay increment (D-l) shall be chosen as a multiple of the interleaver 
block length (/). Therefore, M xl= (D-1), where the parameter M is an integer. The characteristics of convolutional 
interleaving are shown in Annex C. Table 19 summarizes interleaving depth, interleaving (and de -interleaving) memory 
size, and end-to-end delay. The correction capability is calculated using t = number of octets that can be corrected by 
RS codewords which equals half the number of redundancy octets (R/2) and q = length of RS codeword divided by the 
length of an interleaved block (N/I). 

Table 19: Characteristics of triangular, convolutional interleaver 



Parameter 


Value 


Interleaver block length 


I octets (I must divide N) 


Interleaving depth D 


IVI X I + 1 octets 


(De)interleaver memory size 


M xlx (I- 1)/2 octets 


End-to-end delay 


IVI xlx (1-1) octets 


Correction capability 


Lt/qJxMx (1+1) octets 



6.4.4 Framing 



6.4.4.1 



Frame description 



A frame is a set of octets carried by one DMT symbol. The frame frequency depends on the length of the cyclic 
extension. A frame is composed of two sources: the "fast" buffer and the "interleaved" buffer. The index / refers to 
parameters related to the fast or interleaved buffers ( ;' e {f , l})- The inclusion of the fast buffer is optional. When the 
fast buffer is not included, the interleaved buffer can carry non-interleaved data by setting the interleaver depth to zero. 

Both the fast and interleaved buffers contain an integer number of RS-encoded octets. Neither the fast nor the 
interleaved buffer is required to carry an integer number of RS codewords. To reduce the end-to-end delay, it is 
recommended that the fast buffer (or the interleaved buffer when the interleaver depth is zero) carries at least one RS 
codeword. The framing parameters are exchanged between the VTU-O and VTU-R during initialisation. 
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The framing rules described in this clause are summarised in figure 34: 




frame #1 ■ 



-^-e- 



frame #2 



Figure 34: Framing description 



6.4.4.2 



Payload adaptation 



Payload traffic 
Adaptation 



Fast or slow 
octet insertion 



RS dummy insertion 



Partitioning before 
RS encoding 



After RS encoding 



Fast or interleaved 
buffer delineation 



Fast and interleaved 
buffer merge 



Each frame shall carry an integer number of TPS-TC payload octets provided by the o/p interface. To map TPS-TC 
payload octets at a rate multiple of 64 kbps into a frame, it is required to stuff the TPS-TC octet flow with dummies. For 
a payload data rate of n, x 64 kbps rate, we have on average n, x 8 000/fs octets per frame, with/, the frame rate 
(i.e. DMT-symbol frequency). 

We define k as the number of TPS-TC payload octets carried in a sequence of H = 138 frames at a payload data rate of 
64 kbps. (Since the cyclic extension LcpH- Lcs- P is a multiple of 2"^', we always have an integer number of TPS-TC 
payload octets every // = 1 38 frames. If the cyclic extension Lcp + Lcs - P is equal to 40 X 2", then the frame rate is 
4 kHz and any value of H would result in an integer number of TPS-TC payload octets per H frames). 

, HxSOOO 

k — bytes 

f 

J s 

When the payload data rate is equal to n, x 64kbps, then n, x k payload octets are carried in // = 138 frames. In order to 
transport an integer number of TPS-TC payload octets per frame, an appropriate number of dummy octets may have to 
be inserted into the stream of TPS-TC payload octets. Every frame will contain a total of f/, octets 
(TPS-TC octets h- dummy octets), with: 



u = 



riiXk 
H 



ETSI 



62 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



The number of dummy octets Dzj to be inserted every H packets is then: 

n:Xk 



Dzj = 



H 



xH -{n.xk) 



These dummy octets are inserted in the last position of the first Dzj packets of f/, octets in a sequence of H frames 
(figure 34). The value of the Dzj dummies is 0x3 A. 



6.4.4.3 Reed-Solomon encoding 

After payload adaptation, £, overhead octets are added to the head-end of each packet of [/, octets (figure 34). These 
octets are called fast and slow octets for the fast and slow channel, respectively (clause 6.4.4.4). Next, a sequence of A^, 
packets of (£, + L'^,) octets is RS-encoded. In order to achieve an integer number of RS-codewords per A^, packets, 
RS -dummy octets may have to be inserted. The RS -codeword length is equal to the parameter A^, . 



The number of RS-encoded octets, B„ per A^, packets is given by: 



b^ = [nMe,+u^)+d,J 



X- 






In the above equation, the parameter A^, denotes both the number of packets of (£, + Ui) octets and also the length of an 
RS-codeword (in octets). The parameter Ki is the number of information octets in an RS-codeword. 

The number of RS dummy octets, Drs.i , inserted to carry an integer number of RS-codewords in every A^, frames is 
given by 



D,sj = 



nMe.+u,) 



K, 



xK,-N,x{E.+ U,) 



Each one of the £);?5, dummies is inserted at the tail-end of the first D^^,, packets of (£■,-!- L'^,) octets in a sequence of A^, 
packets (figure 34). The value of the Drs.i octets is OxD3. 

After RS-dummy insertion, the number of RS-encoded octets per frame carried in either the fast or interleaved buffer is 
given by: 



^_fi. _ A^,x(£, + ^,)+D,,, _ 



iV,x (£,+[/,)■ 



K: 



Note that the paramter B, = P, A^, represents both the number of octets in A^, frames (with P, octets per frame) and also 
the number of octets in P, codewords (with A^, octets per codeword). 
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6.4.4.4 



Superframe description and contents of fast and slow octets 



A superframe is composed of 10 packets of {/,+£■, octets. Each packet within the superframe transports £, fast or slow 
octets (in the fast and slow channel, respectively). The content of these octets is summarised in table 20. If the fast 
buffer is empty, the F-EOC octets are transported in the S-EOC octets. Otherwise the S-EOC octets are replaced with 
payload octets. There are V VOC octets per packet; they are always transported in the slow channel. A setting of V=l 
shall be supported, other values for V are optional. The fast and slow dummy octets shall have the value OxFF. 

If the fast path is active, the NTR octet and IB octet in the slow channel shall be replaced with dummy octets. 

Table 20: Contents of fast and slow octets 



Packet 


Fast octets 


Slow octets 








First octet 


Other octets 
(if any) 


First octet 


Octets 2 to (1^+1) 


other octets 
(if any) 


1 


F-CRC 


F-EOC 


S-CRC 


VOC 


S-EOC/payload 


2 


Synch octet 


F-EOC 


Synch octet 


VOC 


S-EOC/payload 


3 to 5 


IB 


F-EOC 


IB/dummy 


VOC 


S-EOC/payload 


6 


NTR 


F-EOC 


NTR/dummy 


VOC 


S-EOC/payload 


7 to 10 


Dummy 


F-EOC 


Dummy 


VOC 


S-EOC/payload 



6.4.4.4.1 



Cyclic redundancy check 



Two cyclic redundancy checks (CRCs), one for the fast buffer and one for the interleaved buffer, shall be generated for 
each superframe and transmitted in the first packet of the following superframe. The CRC in the first superframe shall 
be set to zero. Eight bits per buffer type (fast or interleaved) per superframe are allocated to the CRC check bits. These 
bits are computed from the k message bits using the equation: 



crc(D)= M(D) D' modulo G(D) 



where 



M(D) = moD''"'H-m|D''"^H- ... H-mk.2DH-mk.| is the message polynomial 

G(D) = D'*h-D'*h-D^h-D^h-1 is the generating polynomial, 

crc(D) = C()D' + CiD'' h- . . . h- CgD + c^ is the check polynomial, 

D is the delay operator. 

That is, crc is the remainder when M(D)D^ is divided by G(D). 

The bits covered by the CRC include: 

• fast buffer: all bits of the fast buffer before RS encoding, except the CRC; 

• interleaved buffer: all bits of the interleaved buffer before RS encoding, except the CRC. 
Each octet shall be clocked into the CRC with least significant bit first. 

6.4.4.4.2 Synchronisation octet 

The synchronisation octet has the value Ox3C. This synchronisation octet is used to monitor the frame synchronisation. 
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6.4.4.4.3 



Indicator bits (IB) 



The indicator bits are used to transmit far-end defects and anomalies. The description of the contents of the three 
indicator octets are described in table 21. If the fast channel is active, the indicator octets are transmitted in this channel, 
and the indicator octets in the slow channel are replaced by dummies. 

Table 21 : Content of indicator bits 



Octet* 


Blt# 


Definition 


1 


bO to b7 


Reserved for future use 


2 


bO 


Febe-s 


b1 


Ffec-s 


b2 


Febe-f 


b3 


Ffec-f 


b4 


Flos 


b5 


Rdi 


b6 


Fpo 


b7 


Flpr 


3 


bO 


LoM (loss of margin) 


b1 


Fhec-s (used for ATM only, shall be set to for STM) 


b2 


Fhec-f (used for ATM only, shall be set to for STM) 


bS 


Fncd-s/Focd-s (used for ATM only, shall be set to for STM) 


b4 


Fncd-f/Focd-f (used for ATM only, shall be set to for STM) 


b5 to b7 


Reserved for future use 



The active state of a bit is one (high). Bits that are not used are set to zero (low). The LoM bit shall signal the loss of 
margin at the far end. It shall become high once loss of margin is detected and shall remain high as long as this 
condition exists. 



6.4.4.4.4 



Network Timing Reference (NTR) 



Isochronous services require the same timing reference at transmit and receive sides in higher layers of the protocol 
stack. To support the transmission of this timing signal, the VDSL system will transport an 8 kHz timing marker. 

For applications that require NTR, it will be transported as follows: 

• The VTU-O will derive a local 8 kHz timing reference (LTR) by dividing its sample clock by the appropriate 
number. For a VDSL system using Nsc = 256 x 2" tones, the sampling frequency could be 2NscAf and the 
divisor would then be 69 x 2°"^^. 

• The VTU-O shall estimate the change in phase offset between the NTR and the LTR from the previous 
superframe to the present. This value shall be expressed in cycles of a clock running at frequency 2NscAf and 
shall be transported in the NTR overhead octet (see table 20) as a 2's-complement number. 

• A positive value of the change in phase offset shall indicate that the LTR has a higher frequency than the NTR. 
A negative value of the change in phase offset shall indicate that the LTR has a lower frequency than the NTR. 

The LTR, being proportional to Af, has a maximum frequency variation of 50 ppm. The NTR has a maximum 
frequency variation of 32 ppm. The combined maximum difference is therefore 82 ppm. This would result in a 
combined maximum phase offset of 205 ns per superframe. This corresponds to approximately 0,45 x 2" samples. For 
the largest value of n (n = 4), this is slightly more than 7 samples (in the positive or negative direction). One octet of 
information is therefore sufficient to code the phase offset. 
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6.4.4.5 



Convergence of fast and interleaved buffers 



Data from the interleaved and (optional) fast buffer are combined so that in each frame there is first a segment of fast 
data followed by a segment of interleaved data. Figure 35 illustrates this process. 



data from the fast buffer 



data from the interleaved buffer 



p multiplexed, RS-encoded data ^ 

Figure 35: Convergence of the fast and interleaved data into one frame 

The total number of RS-encoded octets per frame, P^^^^/ , is given by 



total 



P +P 



where Pj and Pp are the number of RS-encoded octets from the interleaved and fast paths. 

6.5 PMS-TC for single carrier modulation 
6.5.1 Transmission frame format 

The format of the transmission frame, as shown in figure 36, shall be applied in both the upstream and downstream 
directions. The frame shall contain 405 octets: 

• a 5-octet header; 

• and a 400-octet payload. 



405 octets 



Header: 5 octets 



Payload: 400 octets 



Sync 

Word 

2 octets 


Control 

Word 

3 octets 


Fast 
Channel 
F octets 


Slow 
Channel 
5 octets 


Fast 
Channel 
F octets 


Slow 
Channel 
S octets 



Figure 36: Transmission Frame Format 

The transmission frame payload consists of two fields for the Fast channel and two fields for the Slow channel which 
are alternated as shown in figure 36. 

Each Fast channel field (F-octets) transports one Reed-Solomon codeword with no interleaving. Each Slow channel 
field (5-octets) transports one Reed-Solomon codeword which shall pass through a convolutional interleaver before 
transmission onto the line. 

Both F and S values are even and depend on the applied Transport Class, as defined in table 26, set during the system 
configuration. If the Transport Class 1 (single latency) is applied, the setting is F = 0, S = 200. 

All frame octets are transmitted MSB first. The MSB of the first transmitted frame octet corresponds to the beginning of 
the frame. 
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6.5.1.1 



Fast codeword structure 



The structure of a Fast codeword is as shown in figure 37. The codeword consists of a Fast Payload field of PF octets 
and Fast FEC field of RF octets so that {PF + RF = F). The maximum length of the Fast codeword is 1 80 octets, the 
minimum length is octets. 

Nonzero values of PF and RF are optional; the valid nonzero PF values (Transport Class 2) can be derived from 
table 26. The number of RF octets may get values 0, 2, 4 or 16. The value provides an uncoded data transmission over 
the Fast channel. The first Fast codeword octet occurring in figure 36 corresponds to the first Fast Payload octet shown 
in figure 37. 



Fast codeword: (PF+RF) < 180 octets 


J 


' 


Fast Payload 
PF octets 


Fast FEC 
RF octets 



Figure 37: Structure of Fast Codeword 

NOTE: For an uncoded implementation of the Fast channel the standard method of the line -related error 

monitoring verification (by using corrupted FEC as described in clause 6.5.3) is not applicable. The 
verification method in this case shall be proprietary and may be done on the transport protocol layer 
(by the corresponding TPS-TC) or on the application layer. 



6.5.1.2 



Slow codeword structure 



The structure of a Slow codeword (prior to interleaving) is presented in figure 38. The codeword consists of 3-octet 
Operations Channel (OC) field, a Slow Payload field of PS octets, and a Slow FEC field of 16 octets so that 
(OC + PS + 16 = 5). The maximum length of the Slow codeword is 200 octets, the minimum length is 20 octets. The 
valid values of PS can be derived from table 26. The first Slow codeword octet occurring in figure 38 corresponds to the 
first OC octet shown in figure 39. The individual octets of the Slow codeword are subject to convolutional interleaving 
prior to transmission onto the line. 



Slow codeword: 20 < (3+P5'+16) <200 octets 



Operations 
Channel (OC) 
3 octets 



Slow Payload 
PS octets 



Slow FEC 
16 octets 



Figure 38: Structure of Slow Codeword 

The structure of the OC field is shown in figure 39. The first OC octet is OPCODE, the second and third are DATA 
octets. The OPCODE indicates the transmitted OC message; the DATA octet supplies the corresponding data. 
The OC field is shared between the embedded operations channel (eoc) and the VDSL Overhead Control (VOC) 
channel as described in clause 6.2.3. 



* 




Operations Channel (OC) = 3 octets 


J 




OPCODE 

1 octet 


DATA 

2 octets 



Figure 39: Structure of the Operations Channel Field 
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6.5.1.3 



Frame header octet definition 



The transmission frame header includes a 2-octet Syncword and a 3-octet Control field. The Syncword contains frame 
alignment information. The Control field is intended to convey the following delay sensitive synchronisation, 
management, and service information: 

NTR marker (NTR); 

link activation support flags {r_trig/o_trig, rjlag); 

far-end PMD layer defects/failures (flos, flos_crl, flosjorl); 

far-end PMS-TC layer defects/failures (fsef); 

far-end TPS-TC layer defects/failures (fp); 

VTU-R power loss (flpr, FPO); 

reserved for future application; 

reserved for proprietary use. 

The header also includes the header cyclic redundancy check, providing Control field error detection. 

The header octet description is presented in table 22. In all header octets bit 7 is the MSB. Bit 7 of octet shall be 
transmitted first. 

Table 22: Allocation of the Frame Header Octets 



Octet 


Name 


Description 


Value 





Synci 


SyncWord, octet 1 


0xF6 


1 


Sync 2 


SyncWord, octet 2 


0x28 


2 


Control 1 


Control and Management information, word 1 


Variable 


3 


Control 2 


Control and Management information, word 2 


4 


Control 3 


Control and Management information, word 3 



6.5.1.3.1 



Syncword octets 



The SyncWord is intended for transmission frame delineation at both the VTU-O and VTU-R. It shall consist of two 
octets with fixed values: 



• Sync 1 = 0xF6; 

• Sync 2 = 0x28. 



£75/ 



68 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



6.5.1.3.2 



Control 1 octet 



The Control 1 octet shall contain the NTR-hit, the o/r_trig and o/rjlag bits, used for the link activation support and the 
first five Indicator Bits (IB), intended for the far end monitoring. The Control 1 octet description is presented in 
table 23. All IB are coded "0" for normal operation, "1" for abnormal operation (defect or failure condition). 

Table 23: Control 1 Octet Description 



Bit 


Name 


Description 


Value 


Note 


7 


trig 


"o_trig" signal in downstream direction 
"r trig" signal in upstream direction 


"0" for normal state, "1 " for the 
active state 


see clause 
8.3.7 


6 


flag 


"ojlag" signal in downstream direction 
"r flag" signal in upstream direction 


"0" for normal state, "1 " for the 
active state 


see clause 
8.3.7 


5 


IB-1 (fp 1) 


Far-end TPS TC #1 defect/failure 


"0" for normal state, "1" for 
the relevant TPS-TC 

failure condition 


see notes 
1 , 2 and 3 


4 


IB-2 (fp_2) 


Far-end TPS_TC #2 defect/failure 


3 


IB-3 (fp 3) 


Far-end TPS TC #3 defect/failure 


2 


IB-4 (fp 4) 


Far-end TPS TC #4 defect/failure 


1 


IB-5 


Reserved for additional defects/failures 









NTR 


NTR marker 


"1" if NTR marker is 
transmitted, "0" otherwise 


see clause 
6.5.1.3.6 


NOTE 1 : Far-end pass defect/failure indicators {fp) shall be used for path-related primitives for possible 

paths numbered from #1 to #4. Additional path failures can be indicated using spare bits of the 

Control octets 1 and 2. The dedicated fp shall be specified in accordance with the applied path 

(applied TPS-TC). 
NOTE 2: The definition of any fp shall coincide with the relevant path-related defect/failure primitive definition 

in clause 7.3. Particularly, for the ATIVI path, the fp shall indicate the Far-end Loss of Cell 

Delineation defect {fled), as it defined in clause 7.3.2. 
NOTE 3: If ATIVI is applied in a single latency mode, the fp_1 shall be used to indicate the flee/ defect for the 

Slow ATIVI TC. In a dual latency mode, the fp 2 shall be additionally used to indicate the fled defect 

for the Fast ATIVI TC. 



6.5.1.3.3 



Control 2 octet 



The Control 2 octet shall contain the first and the second CRC bits and the next six IB. The Control 2 octet description 
is presented in table 24. All IB are coded "0" for normal operation, "1" for abnormal operation (defect or failure 
condition). The CRC_1 and CRC_2 bits shall be assigned as described in clause 6.5.1.3.5. 

Table 24: Control 2 Octet Description 



Bit 


Name 


Description 


Value 


Note 


7 


CRC 1 


Frame header CRC check 


As defined in clause 6.5.1 .3.5 


First bit 


6 


IB-6 


IB reserved for further 
applications 






5 


IB-7 
(flos cri) 


Far-end Loss of Carrier 1 energy 


"0" for normal state, "1" for the loss 
state 


See clause 
7.7.1 


4 


IB-8 
(flos_cr2) 


Far-end Loss of Carrier 2 energy 


"0" for normal state, "1" for the loss 
state 


See clause 
7.7.1 


3 


IB-9 (rdi) 


Far-end Remote defect indication 


"0" for normal state, "1" for the loss 
state 


See clause 
7.3.1.4 


2 


IB-10 


IB reserved for further 
applications 






1 


IB-11 


IB reserved for further 
applications 









CRC 2 


Frame header CRC check 


As defined in clause 6.5.1 .3.5 


Second bit 
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6.5.1.3.4 



Control 3 octet 



The Control 3 octet shall contain the third and the fourth CRC bits, two IB bits and four bits for proprietary use. The 
Control 3 octet description is presented in table 25. All IB are coded "0" for normal operation, "1" for abnormal 
operation (defect or failure condition). The CRC_3 and CRC_4 bits shall be assigned as described in clause 6.5.1.3.5. 

Table 25: Control 3 Octet Description 



Bit 


Name 


Description 


Value 


Note 


7 


CRC 3 


Frame header CRC check 


As defined in clause 6.5.1 .3.5 


Third bit 


6 


IB-12(fpo) 


Far-end Power-off failure 


"0" for normal state, "1 " for the power 
failure state 


See clause 
7.3.3 


5 


IB-13(flpr) 


Far-end Loss-of-Power defect ("dying 
gasp") 


"0" for normal state, "1 " for the power 
failure state 


See clause 
7.3.3 


1 to 4 




Reserved for proprietary applications 









CRC 4 


Frame header RC check 


As defined in clause 6.5.1 .3.5 


Fourth bit 



6.5.1.3.5 CRC-bits 

The CRC bits CRC_1 to CRC_4 are computed as a remainder of multiplying the polynomial: 

mgD^^ -I- n\D^'^+. . .+m^^ by D'* and then dividing by D'* -I- D -I- 1 . 

The polynomial coefficient Mq is the MSB of the first Control 1 octet, m2^ is the LSB of Control 3 octet and 
mg , mjj , mjg , mjj = . The CRC_1 is the MSB of the remainder; the CRC_4 is the LSB of the remainder. 



6.5.1.3.6 



NTR transport and NTR marker generation 



An 8 kHz NTR is conveyed from the VTU-O to VTU-R by synchronising the downstream transmission frame 
boundaries with NTR and transmitting an NTR marker in the frame header, as described in clause 6.5.1.3.2. The NTR is 
reconstructed at the VTU-R using the received NTR marker. An NTR marker for the transmission profile with the bit 
rate of N x 67,5 kb/s shall be generated every 384/Q NTR periods (i.e. every 48/Q ms the NTR marker will transition 
from low to high level), where Q is the greatest common divisor of 384 and N. 

NOTE: The NTR marker shall be set the the value 1 once every N/Q transmission frames. For example, for 
N = 48 (TR = 3,24 Mb/s) the number of transmission frames between two adjacent NTR markers 
equals 1, and the number of NTR periods between two adjacent NTR markers equals 8. Correspondingly, 
the NTR marker is inserted every 1 ms. 

6.5.1 .4 Frame transport classes 

The transmission frame transport class defines the number of S, F and RF octets in the transmission frame. The 
mandatory Class 1 provides a single latency transport. The optional Class 2 provides a dual latency transport. 

A Class 1 frame includes two Slow codewords of 200 octets each. A Class 2 frame is defined by the values F and RF, 
and respectively denoted as {F/RF\, where RF could be 2, 4 or 16, F is even and less than 180. In the same manner. 
Class 1 frame is denoted as [0/0]. 

NOTE: A Class 2 frame denoted [12/8], for example, defines a frame which contains two Fast codewords with 
4 Fast Payload octets, 8 Fast EEC octets and a Slow codeword with 200-12 =188 octets (3 OC octets, 
169 Slow Payload octets and 16 Slow EEC octets). 

The transmission frame structure of a single and dual latency transport classes is summarised in table 26. 

Table 26: Frame Transport Classes 



Class 


Slow Data 
S, octets 


Fast Data 
F, octets 


Fast Redundancy 
RF, octets 


Symbol 


Mode 


Notes 


1 


200 








[0/0] 


Single latency 


Mandatory 


2 


200- F 


F = 2to 180 


RF = 2, 4, 16 


[F/RF] 


Dual latency 


Optional 
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6.5.1.5 



Frame delineation algorithm 



The frame delineation algorithm shall be left to the discretion of the vendor. The recommended algorithm and frame 
delineation state machine is based on Syncword detection at the expected locations (Sync_Events) and is described in 
annex B.l. 

6.5.2 Data randomisation and de-randomisation 

Randomisation shall be performed in both transmission directions by the same randomisation algorithm before the RS 
encoding. Data de -randomisation shall be performed after the RS decoding. Randomisation/de -randomisation shall be 
performed on the frame header, except Syncl, Sync2 octets, and on the frame payload, except RS redundancy octets. 
The header. Fast codewords and Slow codewords (except RS redundancy octets) transmitted in the same direction are 
randomised separately by the same randomisation algorithm. 

NOTE: The randomiser/de-randomiser is supposed to be self-synchronising by the implementation. 

The randomisation algorithm in both VTU-O and VTU-R shall comply to: 



out in out out 



n-23 



The de-randomisation algorithm shall reconstruct the randomised data. The block diagram of the randomiser is 
presented in figure 40. 



Di(n) 



I 



Serial input, MSB first 



O 




Do(n) 



Do(n-l) Do(n-2) 



Do(n-18) 



Do(n-23) 



Serial output, MSB first 

Figure 40: Randomiser 



6.5.3 Forward error correction 

Reed-Solomon (RS) error correction coding shall be used for FEC implementation. RS codes operate on octet-based 
data streams. The applied code RS(N,K) is expressed by convention as two numbers, the first indicating the total 
codeword length (N), and the second indicating the number of data octets (K). The difference between these two 
numbers (N-K) is the number of FEC octets (redundancy octets). 

The error correcting power of an RS code is related to the number of FEC octets N-K. The number of corrected octets f 
per codeword equals L(N-K)/2j, where LxJ denotes truncating to the lower integer. 

The RS codes applied for downstream and upstream data protection shall use as generator polynomial: 

N-K- l 

g(x)= llix + ju'), 

1=0 

where )J. is a root of the binary primitive polynomial: 

X^ +x* +X^ + X^ +1. 
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A data octet is identified within the Galois Field (256), the finite field with 256 elements as: 

7 



{d-id(^d^d^dj^d2d^dQ) <^ 2_,d„ju" <^ //^ ()j.=02hex), 



n=0 

with a one-to-one mapping of octet values {do remains the LSB of the octet, d^ remains the MSB; the MSB shall be 
transmitted first). 

An RS(N,K) codeword shall be defined as a function of the K data octets as: 

where the K most significant octets (coefficients of x° , n=N-K..N-l) correspond to the K input data octets, and the N-K 
least significant octets (coefficients of x" , n=O..N-K-l) correspond to the N-K output FEC octets. 

Because the data octet identification is defined within the Galois Field with 256 elements, RS(N,K) encoding/decoding 
shall be implemented as a shortened RS(255,255-Nh-K) code. At the encoder side, 255-N octets, all set to 0, shall be 
appended before the K data octets at the input of the RS(255,255-Nh-K) encoder. These appended octets shall be 
discarded after the encoding procedure. 

It shall be possible to introduce an intentional corruption of the RS codeword to enable verification of the VDSL link 
error monitoring. The corruption shall be introduced when requested by the management system (clause 7.2.3) into a 
single octet of the FEC redundancy field of either the Slow channel or Fast Channel. 

NOTE: The values of N and K in RS(N, K) correspond to (OC + PS + 16, OC + PS) for the slow code word and 
to (PF + RF, PF) for the fast code word. 



6.5.4 Interleaving 



Interleaving improves the error-correcting power of the RS codes in the presence of impulse noise. Slow codewords of 
the transmission frame shall be interleaved before transmission by a convolutional interleaver, defined by the following 
parameters: 



• 



• 



N = S - incoming codeword length defined by the transmission frame format in table 26; 
/ - interleaver block length, octets; 

• D - interleaving depth, octets; 

• M - interleaving depth index; 

• E - erasure correction, octets. 

The incoming codeword of N octets is divided into interleaver blocks of I octets. The interleaver block length I shall be 
normally equal to N/8. Optionally, it may be equal to N/4 or N/2. The octets within the interleaver blocks are numbered 
from j = to j = I-l. 

The interleaver shall perform by the following rule: 

Each octety of any interleaver block is delayed at the interleaver output by (D - l)y.j octets, where j = 0, 1,2, ... (/ - i) 
is the octet number within the interleaver block, D is the interleaving depth. For example, the first octet of any block 
shall be not delayed, the third octet of any block will be delayed by 2 x (D - 7) octets and so on. 

The value of interleaving depth D shall be chosen in according with the required impulse noise protection (erasure 
correction). The value D-1 characterises the number of octets separating two sequential octets of the same RS codeword 
at the output of the interleaver. For all settings the value of {D - 1) shall be kept as a multiple of the interleaver block 
length 7: 

D = M X I + 1, where the value of M shall be programmable to any integer in the range of to 64. 
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The main characteristics of the interleaver are summarised in table 27. 

Table 27: Interleaver Characteristics 



Parameter 


Value 


Notes 


Block Length (1) 


/ = N/8, N/4 or N/2, octets 


A/=PS+1 9, octets 


Depth (D) 


D = Mx 1+ ^, octets 


M=0 ->64, programmable 


Erasure Correction (E) 


£ = L fx //A/Jx(Mx /+ 1), octets 


f = 8 (RS error correction ability) 


End-to-End Delay (DL) 


DL = Mx lx{l- 1), octets 




Interleaver Memory Size 


MEM=Mx lx{l- 1)/2, octets 




NOTE 1 : The interleaver erasure correction £ defines the maximum number of corrupted sequential 
octets could be corrected by RS algorithm when interleaving is applied. Correspondingly, the 
duration of noise pulses the system is protected from could be calculated as Ex8/R, where R is 
the bit rate of the transmit signal over the line. 

NOTE 2: The U symbols indicates the truncation of the value to the lower integer. 



The maximum value of M required for the given transmission profile shall provide an erasure correction capability up 
to 500 us. An example of interleaver/de-interleaver implementation is presented in annex C. 



7 Operations and maintenance 

7.1 0AM reference model 

7.1.1 0AM framework 

In order to be manageable by operators, a VDSL system needs to comply with the network management framework. 
A number of items are imposed by this framework: 

• the components involved by the GAM framework; 

• the functionality provided by the QAM; 

• the fault and performance monitoring process; 

• the type of entities to monitor. 

7.1 .2 Components of the 0AM framework 

This network management framework contains at least four components: 

• the managed nodes (e.g. a switch), each containing one agent; 

• at least one network management system that monitors and controls the nodes; 

• a network management protocol used by the NMS to exchange management information; 

• the Management Information Base (MIB) containing all management information related to one agent. 

In the VDSL system there is one agent located on the VTU-O side but none on the VTU-R; this object presents a MIB 
to the Network Management Stations containing the consolidated QAM information related to the VDSL link. As all 
MIB objects reside on the VTU-O side, when VTU-R information is required by the NMS, the VTU-O is responsible 
for the retrieval of this information from the VTU-R, using the VDSL OAM dedicated communication channels. 
(According to the expected expansions of the VDSL systems, an agent could be located either in a single VTU-O or a 
common equipment handling multiple VTU-Os; in this latest case, one multi-line MIB is accessible by the NMS.) 
Figure 41 illustrates the components of the VDSL OAM framework. 
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VTU-R 



NMS 



Figure 41 : Components of the 0AM framework for the VDSL link 

Definition of the MIB and the network management protocol are out of scope of the present document. 

7.1.3 0AM functionality 

According to ITU-T Recommendation X.700 [7], QAM functions to be supported by a managed system are classified 
by five functional categories: 

• Configuration management: 

Configuration management relates to the topology of the resources within the managed system. 
Configuration management is responsible for the provision, modification and cessation of capabilities 
within the system. 

• Performance management: 

Performance management enables the behaviour of resources and the effectiveness of communication 
activities to be evaluated. 

• Fault management: 

Fault management encompasses fault detection, isolation and the correction of abnormal operation of the 
managed system. 

Faults cause open systems to fail to meet their operational objectives and they may be persistent or 
transient. 

Faults manifest themselves as particular events (e.g. errors) in the operation of an open system. 

• Security management: 

Security management relates to the integrity of the data in the system and fallback arrangements. This 
category relates to who or what can access the system and its resources. 

• Accounting management: 

Accounting management enables charges to be established for the use of resources and for costs to be 
identified for the use of those resources. 

Components involved by the management of a VDSL link must support Configuration management. Performance 
management and Fault management. Security and Accounting management are not applicable to a VDSL link. 
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7.1 .4 Fault and performance monitoring process 

The general process applicable by an agent for monitoring fault and performance is shown in figure 42. 
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Figure 42: Performance monitoring process 

The following definitions are applicable: 

• Primitives: Primitives are basic measures of performance. Performance primitives include anomalies and 
defects. Primitives may also be basic measures of other quantities (e.g., ac or battery power), usually obtained 
from equipment indicators; 

• Near-end primitives are usually detected by monitoring the local line codes and frame formats; 

• Far-end primitives are detected by reading fields in the overhead that are defined to report the nature and 
number of basic error events or other performance -related occurrences detected at the far-end; 

• Anomalies: An anomaly is a discrepancy between the actual and desired characteristics of an item. The desired 
characteristic may be expressed in the form of a specification. An anomaly may or may not affect the ability of 
an item to perform a required function; 

• Defects: A defect is a limited interruption in the ability to perform a required function. It may or may not lead 
to maintenance action depending on the result of additional analysis. Successive anomalies causing a decrease 
in the ability of an item to perform a required function are considered as a defect; 
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• Failures: A failure is the termination of an item's ability to perform a required function. At a network element, 
both local and remote failures can be observed. Local failures include near-end signal failures. Remote failures 
are those that occur and are recognised elsewhere, and are reported within the transmission signal; 

• Parameters: These parameters are counts of the various impairment events detected during the accumulation 
period. Performance parameters are directly derived from the corresponding performance primitives; 

• Thresholding: All performance parameters (e.g. errored seconds) have associated thresholds, which may be 
set, read, or changed by the Network Management System (NMS) that is doing performance monitoring. 

A threshold crossing for performance parameters may be autonomously reported to the NMS by the VTU-O. 

Figure 43 describes graphically the near-end and far-end concepts applied to a VDSL link. 



VDSL Link 



1 . Detect near-end 
primitives at VTU-R 




6. Detect near-end 
primitives at VTU-O 
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(including loss of VTU-R 
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Figure 43: In-service surveillance of the VDSL link shown from the VTU-O's standpoint 

Primitives and messages apphcable to the VDSL hnk are defined in clause 7.3. 



7.2 



0AM entities 



7.2.1 0AM functional model 

From the OAM point of view, the VDSL link is a system containing several transmission layers, which shall be 
managed. The VDSL link OAM functional model (figure 44) contains OAM entities intended to manage the following 
transmission entities: 

• VDSL Line entity: the physical transport vehicle provided by PMD and PMS-TC transmission sub-layers. 

• VDSL Path entity: the applied transport protocol path, provided by TPS-TC sub-layer. A path could be either 
for a single application (single latency, single transport protocol) or multiple, including optionally different 
transport protocols over single and dual latency. 

• VDSL System entity: the user application path, provided by the layers higher than TC. This path also provides 
the high level OAM functionahty between the VTU-O and the VTU-R. 
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NOTE: The system -related 0AM data flow is currently under study. 

Figure 44: 0AM Functional IVIodel 

The stracture of QAM entities at the VTU-O and VTU-R is identical. The data exchange between peer entities is 
estabhshed over a number of OAM-dedicated communication channels which provide communication between the 
management processes at the VTU-O and VTU-R. 

7.2.2 0AM communication cinannels 

To provide the OAM data transfer between the VTU-O and the VTU-R, the following OAM dedicated communication 
channels shall be arranged: 

• Indicator Bits (IB) channel; 

• VDSL Overhead Control (VOC) channel; 

• embedded operation channel (eoc). 

These three OAM channels shall provide transport of the following OAM data: 

• primitives (anomalies, defects, failures) from all the transmission entities; 

• parameters (performance and testing); 

• configuration control; 

• maintenance. 

The interface between the OAM channel and the corresponding OAM entity is defined by a specific communication 
protocol and a list of transferred information, including a part for proprietary use. Each OAM channel has specific 
characteristics and is intended to bear a specific type of OAM data. Partitioning of the OAM data between different 
OAM channels is described in clause 7.2.3. 
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7.2.2.1 Indicator Bits (IB) 

The transport of the IB is supported by the PMS-TC sub-layer. The IB are used to arrange an OAM communication 
channel between the peer OAM entities intended to transfer all the time-sensitive primitives, which require immediate 
action at the opposite side. The IB channel shall work in unidirectional mode, i.e. independently in both the upstream 
and downstream directions. The main data to be sent over IB is information on defects/failures, for which timing is 
critical. The IB may also transfer other line -related and path-related primitives. 

7.2.2.2 VDSL Overhead Control (VOC) 

The VOC channel is supported by the TPS-TC sub-layer and is intended mainly to transfer VDSL link activation and 
configuration messages between the VTU-O and VTU-R. The VOC channel may also transfer line-related and 
path-related primitives. 

The VOC channel works in bi-directional mode, hence both transmission directions are required to provide 
communication for the VOC. The VOC protocol description and the summary of VOC messages are defined in 

clauses 7.4 and 7.5. 

7.2.2.3 Embedded operation channel (eoc) 

The eoc is supported at the VDSL system (application) layer. The eoc is a clear channel to provide exchange of VDSL 
system management data and control traffic between the VTU-O and VTU-R. The exchanged data includes 
system-related primitives, performance parameters, test parameters, configuration and maintenance. 

The eoc, except in some special cases, works in bi-directional mode using an echoing protocol. Both transmission 
directions are required to provide communication for the eoc. The eoc interface is equal for both the VTU-O and 
VTU-R. It is defined at the y-reference point (clause 6.2.3.1). The eoc protocol is defined in clause 7.6. 
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7.2.3 Partitioning of 0AM data 

The OAM data at both the VTU-O and VTU-R after being collected is stored in the corresponding part of the MIB and 
then can be transferred to the far-end over the corresponding OAM channel. Partitioning of the OAM data between 
different OAM communication channels is summarised in table 28. 

Table 28: OAM Data Partitioning 



OAM Data 


Transferred to the 
far-end by: 


Notes 


Primitives 


Line-related, time-sensitive 


IB 


PMD and PMS-TC defects 


Path-related, time-sensitive 


TP-specific defects/failures (see note 1), separately for 
each TPS-TC 


Line-related, time-insensitive 


IB or VOC 


PMD and PMS-TC anomalies 


Path-related, time-insensitive 


IB or eoc (see note 1) 


TP-specific anomalies, separately for each TPS-TC 


System-related primitives 


IB or eoc (see note 2) 


Power loss primitives 


Parameters 


Line-related, performance 


None 


Calculated from retrieved line related and path-related 
primitives 


Path-related, performance 


Path-related, testing 


eoc 


For some TPS-TC 


Line-related, testing 


ATT, SNR margin and other local measurements 


Self-test 


For some VTU blocks or completely 


VTU Identification 


Vendor ID, revision number, serial number 


Service modules parameters 


Proprietary (SM performance, test or other parameters) 


Configuration 


Line-related parameters 


VOC 


Frame structure, interleaving depth etc. 


Path-related parameters 


eoc 


With respect to the applied TP. 


System-related parameters 


eoc 


Proprietary, with respect to the applied SM 


Maintenance 


VTU state control 


eoc 


Hold the state. Return to normal state 


Self-test activation 


A complete VTU self-test and self sub-tests on specific 
VTU blocks. 


Loopback activation 


At TPS-TC and application layers 


Performance monitoring 
supervision 


Request for FEC corruption test. Notify FEC corruption 
test 


NOTE 1 : The IB are necessary to monitor the primitives which destroy the path (for instance ATM cell delineation 
loss or STM frame delineation loss). The anomalies in the certain active path are monitored by the 
corresponding TPS-TC management function and delivered to the other side by the standard means of 
the applied TP, IB or eoc. 

NOTE 2: eoc is preferable for system-related time-insensitive primitives. 



7.3 OAM primitives and parameters 
7.3.1 Line-related primitives 

Each of the detected line-related primitives is represented by a corresponding indicator at the OAM interface at the a(P) 
reference point. The indicator shall be coded if no anomaly, defect or failure has been registered since the previous 
transmission period, and shall be coded 1 to indicate that at least one anomaly, defect or failure has been registered 
since the previous transmission period. 

All the near-end anomalies, defects and failures shall be represented at both the VTU-O and VTU-R. Representation of 
far-end anomalies, defects and failures at the VTU-R is optional. 
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7.3.1.1 Near-end anomalies 



• 



• 



• 



• 



Forward Error Correction (fec-f): a fec-f anomaly occurs when a received FEC code for the fast data stream 
indicates that errors have been corrected. 

Forward Error Correction (fees): a fec-s anomaly occurs when a received FEC code for the slow data stream 
indicates that errors have been corrected. 

Block Error (be-f): a be-f anomaly occurs when uncorrected errors have been detected in the received block of 
fast data. 

Block Error (be-s): a be-s anomaly occurs when uncorrected errors have been detected in the received block of 
slow data. 



7.3.1.2 Far-end anomalies 

• Far-end Forward Error Correction (ffec-f): a ffec-f anomaly occurs when a fec-f anomaly detected at the far 
end is reported. A ffec-f anomaly terminates when the received fecc-f indicator is set to 0. 

• Far-end Forward Error Correction (ffec-s): a ffec-s anomaly occurs when a fec-s anomaly detected at the far 
end is reported. A ffec-s anomaly terminates when the received fecc-s indicator is set to 0. 

• Far-end Block Error (febe-f): a febe-f anomaly occurs when a be-f anomaly detected at the far end is reported. 
A febe-f anomaly terminates when the received be-f indicator is set to 0. 

• Far-end Block Error (febe-s): a febe-s anomaly occurs when a be-s anomaly detected at the far end is reported. 
A febe-s anomaly terminates when the received be-s indicator is set to 0. 

7.3.1 .3 Near-end defects 



• Loss-of-signal (los): A los defect occurs when the level of the received VDSL signal power averaged over a 
TL second period, is lower than the threshold, and terminates when this level, measured in the same way, is at 
or above the threshold. 

• Severely Errored Frame (sef): The sef defect is managed in accordance with the transmission state diagram. 
A sef defect occurs with a transition out of the SYNCH state and terminates with a transition into the SYNCH 

state. 

NOTE: The value of TL is for further study. 

7.3.1 .4 Far-end defects 



• 



• 



Far-end Loss-Of-Signal (flos): a flos defect occurs when a los defect detected at the far-end and is reported in 
4 or more out of 6 contiguously received indicators. A flos defect terminates when more than 4 indicators out 
of 6 contiguously received indicators are set to 0. 

Far-end Remote Defect Indication (rdi): a rdi defect occurs when a sef defect detected at the far-end and is 
reported. An rdi defect terminates when the received indicator is set to 0. 
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7.3.1 .5 Near-end failures 

• Loss-Of-Signal (LOS): A LOS failure is declared after TSl + 0,5 s of contiguous los defect, or, if los defect is 
present when the criteria of LOF failure declaration have been met. A LOS failure is cleared after TS2 + 0,5 s 
of no los defect. 

• Loss-Of-Frame (LOF): A LOF failure is declared after TFl + 0,5 s of contiguous sef defect, except when a los 
defect or failure is present. A LOF failure is cleared when LOS failure is declared, or after TF2 + 0,5 s of no 
sef defect. 

• Loss-of-power (LPR): A LPR failure is declared after TPl +0,1 s of contiguous occurrence of the Ipr 
primitive. A LPR failure is cleared after TP2 + 0,1 s following power restoration. 

• Power Off (PRO): A PRO failure is declared when the VTU power switch is turned off. The VTU shall be 
fully operable for at least TP3 seconds after its power switch is turned off. 

NOTE: The values of TSl, TS2, TFl, TF2, TPl, TP2 and TP3 may be transmission technology-dependent and 
are for further study. 

7.3.1.6 Far-end failures 

• Far-end Loss-Of-Signal (FLOS): a FLOS failure is declared after TS 1 + 0,5 s of contiguous /Zos defect, or, if a 
flos defect is present when the criteria for LOF failure declaration have been met. A FLOS failure is cleared 
after TS2 + 0,5 s of no flos defect. 

• Far-end Remote Failure Indication (FRFI): an FRFI failure is declared after TRl + 0,5 s of contiguous rdi 
defect, except when a/Zo.s defect or FLOS failure is present. An FRFI failure is cleared when FLOS failure is 
declared, or after TR2 + 0,5 s of no rdi defect. 

• Far-end Loss-of-PoweR (FLPR): a far-end LPR failure is declared after the occurrence of a/Ipr primitive 
followed by TPl + 0,5 s of contiguous near-end los defect. A FLPR failure is cleared after TP2 + 0,1 s of no 
near-end los defect. 

NOTE: The values of TRl and TR2 may be transmission technology-dependent and are for further study. 

7.3.2 Path-related primitives 

All path-related primitives are defined separately for each dedicated path, terminated by the corresponding TPS-TC 
block. The anomalies, defects and failures are different for each transport protocol and so for each dedicated transport 
protocol (e.g. ATM, SDH, IP etc) they shall be represented by OAM indicators specific to the TP. The indicators shall 
be represented at the OAM interface of y_0 (Y_R) reference points. The indicators shall be coded if no primitive has 
been registered during the monitoring period and shall be coded 1 to indicate that the primitive has been registered at 
least once during the monitoring period. 

All the near-end primitives shall be represented at both the VTU-O and VTU-R. Representation of the far-end 
primitives at the VTU-R is optional. 

7.3.2.1 Anomalies, defects and failures for ATM transport 

The set of anomalies, defects and failures for the ATM transport complies with the ITU-T recommendation 1.432 [3]. 
The ATM transport anomalies, defects and failures shall be supported by ATM-TC. If both the Fast and Slow ATM 
transport is established, the two corresponding ATM-TC shall be represented by two equal and independent sets of 
anomalies, defects and failures. 
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7.3.2.1.1 Near-end anomalies 



• 



No Cell Delineation (ncd): a ncd anomaly occurs immediately after ATM Cell TC start-up as long as the cell 
delineation process is in the HUNT or PRESYNC state as defined in ITU-T Recommendation 1.432 [3]. Once 
cell delineation is acquired, subsequent loss of cell delineation shall be considered as ocd anomalies; 

• Out of Cell Delineation (ocd): an ocd anomaly occurs when the cell delineation process transitions from the 
SYNC to the HUNT state as defined in ITU-T Recommendation 1.432.1 [3]. An ocd anomaly terminates when 
the cell delineation process transitions from the PRESYNC to the SYNC state or when the led defect is 
entered. 

• Header Error Check (hec): a hec anomaly occurs when an ATM cell header error check fails. 

NOTE: The ncd anomaly indication is optional. If it is not applied then the ocd anomaly shall be used instead. 

7.3.2.1.2 Far-end anomalies 

• Far-end No Cell Delineation (fried): a fried anomaly occurs when either an ncd or ocd anomaly is detected at 
the far end and is reported by the facd indicator. The facd anomaly always occurs immediately after VTU 
start-up. The facd anomaly terminates when the received _/wcc/ indicator is coded 0. 

• Far-end Out of Cell Delineation (focd): afocd anomaly occurs when an ocd anomaly is detected at the far-end 
and no fncd anomaly is present. Afocd anomaly terminates if the received/ocd/ indicator is coded 0. 

• Far-end Header Error Check (fhec): afriec anomaly occurs when a hec anomaly is detected at the far end and 
is reported by the fhec indicator. The fhec anomaly terminates when a received /Tzec indicator is set to 0. 

NOTE: Both the focd and fhec anomaly indicators are optional. 

7.3.2.1.3 Near-end defects 

• Loss of Cell Delineation (led): an led defect occurs when at least one ocd anomaly has persisted for more than 
TDl ms and no sef defect is present. An led defect terminates when no ocd anomaly is present for more than 
TD2 ms. 

7.3.2.1.4 Far-end defects 

• Far-end Loss of Cell Delineation (fled): an fled defect occurs when an led is detected at the far-end. An fled 
defect occurs when either afocd or facd anomaly has persisted for more than TDl ms and no rdi defect is 
present. An fled defect terminates if neither afocd nor a facd anomaly is present for more than TD2 ms. 

NOTE: The values of TDl and TD2 are for further study. 

7.3.2.1.5 Near-end failures 



• 



• 



No Cell Delineation (NCD): an NCD failure is declared when an ncd anomaly persists for more than 
TNI + 0,5 s. An NCD failure terminates when no ncd anomaly is present for more than TN2 + 0,5 s. 

Loss of Cell Delineation (LCD): an LCD failure is declared when an led defect persists for more than 
TLl + 0,5 s. An LCD failure terminates when no led anomaly is present for more than TL2 + 0,5 s. 



NOTE: The values of TNI, TN2, TLl and TL2 are for further study. 
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7.3.2.1.6 Far-end failures 



• 



• 



Far-end No Cell Delineation (FNCD): an FNCD failure is declared when an fried anomaly persists for more 
than TNI + 0,5 s. An FNCD failure terminates when no fried anomaly is present for more than TN2 + 0,5 s. 

Far-end Loss of Cell Delineation (FLCD): an FLCD failure is declared when an fled defect persists for more 
than TLl + 0,5 s. An FLCD failure terminates when no fled anomaly is present for more than TL2 + 0,5 s. 



7.3.2.2 Anomalies, defects and failures for STM transport 

This is for further study. 

7.3.3 Power- related primitives 

Power related primitives shall be represented by the corresponding indicators at the system level. The indicators shall be 
coded if no power primitive has been registered during the monitoring period and shall be coded 1 to indicate that at 
least once a power primitive has been registered during the monitoring period. 

The near-end primitives shall be represented at both the VTU-O and VTU-R. The far-end primitives shall be 
represented at the VTU-O only. 

7.3.3.1 Near-end primitives 

• Loss-ofrpower (Ipr): an Ipr primitive occurs when the VTU power supply (mains) voltage drops to a level 
equal to or below the manufacturer-determined level required for proper VTU operation. An Ipr primitive 
terminates when the voltage level exceeds the manufacturer-determined minimum level. 

• Power-off (po): apo primitive occurs when the VTU power supply is going to be switched off by the operator 
to terminate the service. The po primitive terminates when the VTU power supply is switched on. 

NOTE: The po primitive is optional. 

7.3.3.2 Far-end primitives 

• Far-end Loss-ofrpower (flpr): aflpr primitive occurs when an Ipr primitive is detected at the VTU-R. Aflpr 
primitive terminates after TPl s of no far-end Ipr indicator is received and no near-end los defect is present. 

• Far-end Power-off (fryo): afr?o primitive occurs when a po primitive is detected at the VTU-R and reported by 
the/5o indicator. Afpo primitive terminates after TP2 s of no far-end /?o indicator and no near-end los defect is 
present. 

NOTE 1: The^o indicator is optional. 

NOTE 2: The values of TPl and TP2 are for further study. 
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7.3.4 Far-end indicators 

Far-end indicators deliver the far-end primitives between the VTU-O and the VTU-R. All indicators shall be transmitted 
periodically to update the information on far-end primitives while the system is in a Steady-State Transmission state. 
Indicators of far-end loss of signal (flos) and the far-end power related primitives (flpr, fpo) still have to be transmitted 
when the system is in Deactivated Power Save (Idle) state. The transfer mechanism of the indicators depends on the 
applied transmission technology. The minimum set of required far-end indicators is presented in table 29. 

Table 29: A minimum set of far-end indicators 



Indicator 


Description 


Note 


Line-Related 


febe-s 


Reports non-corrected errors in the slow data stream 




febe-f 


Reports non-corrected errors in the fast data stream 




fecc-s 


Reports corrected errors in the slow data stream 




fecc-f 


Reports corrected errors in the fast data stream 




flos 


Reports a loss of received signal energy 


Applicable in the power 
saving state 


rdi 


Reports severe frame errors 




Power-related (System-related) 


flpr 


Reports that the supply voltage has dropped below a 
pre-defined level 


Applicable in the power 
saving state 


fpo 


Reports that the power on/off switch has been turned off 


Optional. Applicable in the 
power saving state 


ATM path-related 


fncd 


Reports a loss of cell delineation anomaly 




fhec 


Reports HEC errors 


Optional 


SDH path-related 


Reserved 


Other path-related 


Reserved 



7.3.5 Performance parameters 



The defined set of performance parameters shall describe both line -related and path-related parameters at the VTU-O 
and VTU-R. 



7.3.5.1 



Defect and failure counters 



Counters shall be provided for each near-end and far-end defect and failure. A particular defect or failure count is the 
number of occurrences of that event, where that event occurs when the defect or failure is declared and ends when the 
defect or failure clears. 



7.3.5.2 



Line-related performance parameters 



The line-related performance parameters are calculated using the related anomalies. The calculation method is for 
further study. 



7.3.5.3 



Path-related performance parameters 



The path-related performance parameters are calculated for each applied TP separately, in accordance with the 
corresponding definitions for that TP. If the same TP is applied for both the fast and slow channels, separate 
performance parameters for each shall be calculated. 
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7.3.5.3.1 ATM path-related performance parameters 

• HEC violation count (hec_vc): the hec_vc performance parameter is a count of the number of occurrences of a 
hec anomaly. 

• HEC total cell count (hec_tcc): the hec_tcc performance parameter is a count of the total number of cells that 
have passed through the cell delineation process while in the SYNC state. 

• User total cell count (tec): the tec performance parameter is a count of the total number of cells delivered at 
the Y-O (for the VTU-O) or y-R (for the VTU-R) interface. 

7.3.5.3.2 SDH path-related performance parameters 

The path-related performance parameters for SDH transport are for further study. 

7.3.6 Test parameters 

The near-end test parameters shall be provided at both the VTU-O and VTU-R; the far-end test parameters shall be 
provided at the VTU-O only. 

7.3.6.1 Near-end test parameters 

• Line attenuation (ATN): the ATN is the difference in dB between the power received at the near-end and that 
transmitted from the far-end. The ATA^ ranges from dB to 63,75 dB with 0,25 dB steps. 

• Signal-to-noise ratio margin (SNR_M): the 5A^/?_M represents the amount of increased received noise (in dB) 
relative to the noise power that the system is designed to tolerate and still meet the target BER of 10"^, 
accounting for all coding gains included in the design. The SNR_M margin ranges from -31,75 dB to 
H-31,75 dB with 0,25 dB steps. 

7.3.6.2 Far-end test parameters 

• Far-end line attenuation (FATN): the FATN is measured at the VTU-R and reported back to the VTU-O. The 
attenuation ranges from dB to 63,75 dB in 0,25 dB steps. 

• Far-end signal-to-noise ratio margin (FSNR_M): the FSNR_M is the signal-to-noise ratio margin measured at 
the VTU-R and reported back to the VTU-O. The SNR_M ranges from -31,75 dB to H-31,75 dB in 0,25 dB 
steps. 

NOTE: The ATN and SNR_M test parameters shall be provided "on-demand" at any time following the 
initialisation of the system. There is no requirement to continuously monitor them. 

7.3.6.3 Self-test results 

Both near-end and far-end self-tests are performed "on-demand". A self-test can be defined for any VTU block as well 
as the whole unit. The result of any type of self-test is stored and can be accessed as an "on demand" test parameter. 
This is for further study. 

7.4 Multi-carrier VDSL overhead channel (VOC) 
7.4.1 VOC bandwidth 

A VDSL overhead control channel shall be included to support overhead functions. The raw VOC channel data rate is 
specified as SfjV kbps where fs is the DMT symbol rate expressed in kHz and V is the number of VOC octets per frame 
(clause 5.1.2.2). The mechanism used to support the VOC channel is described in detail in clause 7.4.2. 
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7.4.2 VOC protocol 



All VOC messages shall be transmitted five consecutive times to improve the probability of proper reception and 
decoding. A transceiver unit shall only act on a VOC message if it has received three identical messages in a time 
period spanning five of that particular message. When an unrecognisable command is received (less than three identical 
values in any sequence of five), no action shall be taken. Between two consecutive messages, at least 20 idle octets shall 
be transmitted. The idle octets have a value of 0x00. 

7.4.3 High-level on-line adaptation 

7.4.3.1 Bit-swapping 

Bit-swapping enables a VDSL system to change the number of bits assigned to a sub-channel, or change the transmit 
energy of a sub-carrier without interrupting the data flow. Bit-swapping is a mandatory feature. 

Either VTU may initiate a bit-swap. The swapping procedures in the upstream and downstream directions are 
independent. 

The "receiver" is defined as the modem that initiates the bit swap. It will transmit the bit swap request message and 
receive the bit swap acknowledge message. The "transmitter" receives the bit swap request and transmits the bit swap 
acknowledge. 

There shall be a maximum of one pending bit swap request at any time in the downstream direction. There shall be a 
maximum of one pending bit swap request at any time in the upstream direction. 

7.4.3.2 Bit-swap channel 

Bit-swaps are conducted using the VOC channel, using the protocol described in clause 7.4.2. 

7.4.3.3 Bit-swap co-ordination 

Bit-swapping is conducted with respect to synchronised counters at the VTU-O and VTU-R. The counters increment by 
one after each bit-swap frame interval. A bit-swap frame interval is defined as the duration of 16 DMT symbols. The 
counters are started and incremented as follows: 

• The VTU-O and VTU-R transmitters shall start their counters immediately after transitioning from 
initialisation to steady-state operation or from dynamic power save state to steady-state operation. The value of 
the counter for the first superframe shall be zero; 

• Each transmitter shall increment its counter after each bit-swap frame; 

• Correspondingly, each receiver shall start its counter immediately after transitioning from initialisation to 
steady-state, and then increment it after receiving each bit-swap frame. 

Counting of bit-swap frames shall be performed modulo 256. 

Any form of restart that requires a transition from initialisation to steady-state shall reset the counter. 

7.4.3.4 Bit-swap request 

Upon detecting that the SNR of one or more sub-channels is degraded, the receiver shall initiate a bit-swap by sending a 
bit-swap request to the transmitter via the VOC channel. It shall be up to the receiver to determine what is considered to 
be degradation. This request tells the transmitter which sub-channels are to be modified. The bit-swap request message 
contains the following: 

• a VOC message header consisting of 8 binary ones to indicate the ensuing bit-swap request; 

• four message fields, each of which consists of an eight-bit command followed by a related 12-bit sub-channel 
index. Valid eight-bit commands for the bit-swap message are shown in table 30. The 12-bit sub-channel index 
is counted from low to high frequencies with the lowest frequency sub-carrier assigned the number zero 
(clause 5.1.2.1.1). 
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Table 30: Bit-swap request commands 



Value 


Interpretation 


00000000 


Do nothing 


00000001 


Increase the allocated number of bits by one 


00000010 


Decrease the allocated number of bits by one 


0000001 1 


Change the transmitted power by the factor +1 dB 


00000100 


Change the transmitted power by the factor +2 dB 


00000101 


Change the transmitted power by the factor +3 dB 


00000110 


Change the transmitted power by the factor -1 dB 


000001 1 1 


Change the transmitted power by the factor -2 dB 


00001 XXX 


Reserved for vendor-specific commands 



For a gi update of A dB, the new value of gi shall be calculated as: 

, 1 



512 



X round (SUxg.xlO^^*) 



The bit-swap request message (the header plus the four message fields) consists of a total of 11 octets. 



7.4.3.5 



Bit-swap acknowledge 



After a VTU (the transmitter) has received a bit-swap request (three identical bit-swap request messages within the span 
of five message-times) the transmitter shall act on the request. Within 400 ms, the transmitter shall first send a bit-swap 
acknowledge, which contains the following: 

• a VOC message header containing 8 binary ones, indicating receipt of the request message; 

• one message field that consists of eight binary ones followed by the eight-bit bit-swap frame counter number, 
which indicates after how many bit-swap frame intervals the bit-swap shall occur. This number shall be at least 
200 greater than the value of the counter when the bit-swap request was received. This corresponds to a 
minimum time delay of 800 ms. 

Specifically, the new bit and/or transmit energy table(s) shall take effect starting from the first symbol of the VDSL 
bit-swap frame specified by the bit-swap frame counter number. In other words, if the bit-swap frame counter number 
contained in the bit-swap acknowledge message is n, then the new table(s) shall take effect starting from the first 
applicable symbol of the nth bit-swap frame. 

When the transmitter correctly receives the message, but is unable to perform the requested action, it shall transmit an 
Unable-To-Comply message (UTC). This message consists of a single octet with a value of OxFO (repeated five times as 
described in clause 7.4.2). 



7.4.3.6 



Bit-swap - Receiver 



The receiver shall start a timer from the moment it sends the bit-swap request. If no acknowledgement has been 
received after 500 ms, the receiver can retransmit the request. After a number of unsuccessful retries, the modem can 
take vendor discretionary action to accomplish bit-swap. 

The receiver shall act on a bit-swap request when it has received three identical bit-swap acknowledge messages within 
a span of five message-times. The receiver shall then wait until the bit-swap frame counter equals the value specified in 
the bit-swap acknowledge. Then, beginning with the first symbol in the next bit-swap frame, the receiver shall: 

• change the bit assignment of the appropriate sub-channels, and, if necessary (clause 5.1 .2.7), perform tone 
re-ordering based on the new sub-channel bit assignment; 

• update applicable receiver parameters of the appropriate sub-channels to account for any changes in their 
transmitted energy. 
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7.4.3.7 



Bit-swap - Transmitter 



After the bit-swap acknowledge has been transmitted, the transmitter shall wait until the bit-swap frame counter equals 
the value specified in the bit-swap acknowledge. Then, beginning with the first symbol in the next bit-swap frame, the 
transmitter shall: 

• change the bit assignment of the appropriate sub-channels and, if necessary (clause 5.1.2.7), perform tone 
re-ordering based on the new sub-channel bit assignment; 

• change the transmitter energy in the appropriate sub-channels by the desired factors. 



7.4.3.8 



Express swapping 



Express swapping enables a VDSL system to change the number of bits assigned to a sub-channel, or change the 
transmit energy of a sub-carrier without any acknowledgements. Express swapping is an option to augment the 
performance of bit-swapping. 

Express swapping: 

• increases the speed of execution for a swap significantly; 

• requires the use of a more sophisticated receiver to monitor the received signal to determine if an express swap 
request has been implemented correctly by the transmitter. 



7.4.3.9 



Express swap request 



Upon detecting changes in a sub-channel's SNR, the receiver shall initiate an express swap by sending an express swap 
request to the transmitter via the VOC channel. 

An express swap command is sent only once and allows alteration of the bit distribution (or gain distribution) on n tones 
through the transmission of a command as shown in table 31. 

Table 31 : Express swap request command 



VOC message Headers 



11110010 



11110011 



VOC message field total length 

Including message header 
(octets) 



2,5 n + 5 for n even 
2,5 n + 4,5 for nodd 



2,5 n + 5 for n even 
2,5 n + 4,5 for nodd 



Interpretation 



Implement express bit-swap 
request for a total of n tones on the 
next bit-swap frame 



Implement express bit-swap 
request for a total of n tones on the 
bit-swap frame after the next one 



An express swap request command contains the following: 

• A VOC message header consisting either the pattern 111 10010 or 1 1 1 1001 1 to indicate the ensuing express 
swap request. The header pattern 1 1 1 10010 means the express swap shall be executed in the next bit-swap 
frame while the pattern 1 1 1 1001 1 means the express swap shall be implemented in the frame following the 
next bit-swap frame; 

• A 12 bit message field to indicate the total number of tones («) whose bit/gain distributions need to be 
updated; 

• n message fields, each of which is 20 bits long. The first 12 bits indicate the sub-channel index. In the next 

8 bits, the upper nibble of 4 bits encodes the new absolute number of bits, which is a number between and a 
maximum of 15, according to 0000 for no bits, 0010 for 2 bits, up to 1111 for 15 bits. The lower nibble of 
4 bits, with the most significant bit as the sign bit, encodes the relative gain by a 2's complement 4-bit quantity 
between -4 dB and H-3,5 dB (with 0,5 dB increments); 

• 4 dummy bits if n is even; 

• An internal 16-bit CRC protection for error detection. 
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Table 32: Express swap request command 



Message 
Header 


ES control 


1 St tone 
index 


1 St tone 

total 
bits/gain 




nth tone 
index 


nfi tone 

total 
bits/gain 


Dummy 
bits 


CRC 


1111001X 
(1 octet) 


Tone count 
(12 bits) 


Tone 
number 
(12 bits) 


# of bits/gain 
(1 octet) 




tone number 
(12 bits) 


# of bits/gain 
(1 octet) 


- n odd 
4 - n even 


16 
bits 



There is no Express-Swap Acknowledge command. The receiver that initiates an express swap shall be responsible for 
monitoring the returned DMT signal to determine if the command has been implemented by the transmitter. If the swap 
has not been detected on the correct superframe, then the receiver assumes that the request has not implemented by the 
transmitter. The express-swap initiating DMT receiver may then elect to repeat the express-swap command, to send 
another VOC command, or to retrain. The express swap command is only sent once to improve speed. The CRC at the 
end of the command follows the same octet CRC protocol as used in initialisation for confirmation of correct receipt of 

message fields. The polynomial used is g(Z)=Z +Z +Z +1 where Z is an advance of one bit period. 

7.4.4 Dynamic rate adaptation 

Dynamic rate adaptation is not allowed. 

7.5 Single carrier VDSL overliead control (VOC) channel 

A VDSL Overhead Control (VOC) is intended to provide the VDSL link maintenance, performance monitoring and 
modification of its transmission parameters at the physical layer. The VOC messages are always originated from the 
VTU-O; the VTU-R replies to the VTU-O on a successful message reception. 

7.5.1 VOC message types 

A VOC message contains an OPCODE octet followed by two DATA octets. The OPCODE value distinguishes the OC 
field contents and indicates the transmitted VOC message. 

Three types of VOC messages are specified: 

• COMMAND-type message, which is sent from the VTU-O to convey information to the VTU-R (WRITE 
command) or to request information from the VTU-R (READ command). 

• ECHO-type message, which is a reply from the VTU-R to acknowledge receipt of a COMMAND-type 

message. 

• STATUS-type message, which could be an IDLE message, an EOC message or an Unable-To-Comply (UTC) 

message. 

7.5.2 VOC message transport 

The VOC messages are carried through the VDSL link by the 3-octet OC field present in each Slow codeword of the 
transmission frame (see clause 6.5). The OC field is also used to the eoc stream as described in clause 6.2.3.2. The VOC 
communication should be highly reliable to avoid an execution of unintended commands in the presence of 
transmission errors. Two layers of protection shall be used in the VOC message transport: 

• EEC and interleaving of the OC field in the transmission frame; 

• special handshake between the VTU-O and VTU-R for COMMAND-type messages. 
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7.5.2.1 



VOC handshake 



The VOC handshake shall only start after the reception of at least four IDLE messages and use the following algorithm. 
At the start of the handshake, both the VTU-O and VTU-R transmit IDLE messages. When a COMMAND message is 
to be sent, the VTU-O begins sending the message and repeats it continuously. The VTU-R shall accept the transmitted 
command after it has received identical messages in three transmission frames in a row. The VTU-R shall then respond 
by sending an ECHO message that corresponds to the command received and repeats it continuously. If the VTU-R is 
unable to comply with the received message, it shall send UTC messages instead of the ECHO message. 

NOTE 1: At either receiver under-sampling of received frames may occur (i.e. not every received frame need be 
sampled during the VOC handshake). 

After the VTU-O receives the correct ECHO or UTC message responses in three frame samples in a row, it shall 
respond to the VTU-R by sending an IDLE message and repeats it continuously. When the VTU-R receives an IDLE 
message it shall cease sending the ECHO or UTC messages and start sending IDLE messages for at least the next four 
consecutive messages. 

The VTU-O shall continue to send the COMMAND message until it detects the correct ECHO or UTC message three 
samples in a row. Similarly, the VTU-R shall continue to send ECHO or UTC message until it receives the IDLE 
message from the VTU-O. The total time taken to perform this handshake at both the VTU-O and VTU-R shall be 
limited to 0,9 s. 

NOTE 2: The VOC handshake process is considered complete when both the VTU-O and the VTU-R have 
resumed sending IDLE messages. 

An example of the handshake process (assuming that the VTU-R can comply with the command) is illustrated in 
figure 45. The solid arrows indicate the COMMAND messages sent by the VTU-O, the dashed arrows represent the 
ECHO message response from the VTU-O and the dotted arrows represent the IDLE messages sent by both ends. Each 
message is sent for a period of time corresponding to the number of transmission frames (prior to interleaving) where 
the OC field contains the indicated message. Because of interleaving and handshake there may be a considerable delay 
between VOC message transitions. 
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Figure 45: Example of a Handshake for a Successfully Communicated Command 



7.5.2.2 



VOC handshake flow charts 



The full VOC handshake process at the VTU-O shall meet the flow chart presented in figure 46, at the VTU-R it shall 
meet the flow chart presented in figure 47. 

NOTE: The following denominations are used in figures 46 and 47: 

• Rx_VOC, Tx_VOC: received and transmitted VOC message respectively; 

• Echo_Count: counter of sampled ECHO/UTC messages (at the VTU-O); 

• Msg_Count: counter of sampled COMMAND-type messages (at the VTU-R). 
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Figure 46: VTU-0 Handshaking Flow Chart 
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NOTE: "Correct Echo" in figure 46 is an ECHO-type message, which corresponds with the sent COIVIIVIAND-type 
message, or a UTC message. 

Figure 47: VTU-R Handshaiting Flow Chart 
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7.5.2.3 



Multiple word communication 



A standard VOC message carries two octets of data, which in some cases is not sufficient. The number of data octets 
carried by a VOC message can be extended by using NEXT_WORD commands as described in clause 7.5.3.4. There 
are two types of multiple word messages: 

WRITE, to send information from the VTU-O to the VTU-R; 

READ, to retrieve information from the VTU-R for the VTU-O. 

A multiple word message consists of a VOC header (the same as a standard VOC message) followed by multiple 
NEXT_WORD messages that include the data. The format of READ and WRITE messages is described in table 40. 

7.5.3 VOC message set 

All VOC messages are grouped according to their overall functionality into four groups: STATUS-type messages 
(table 33), messages used for VDSL performance monitoring (table 34), messages used for VDSL link 
configuration/transmission parameters modification (table 36 and 39) and control messages (table 40). The tables 
provide indication of the message status, which is mandatory (M) or optional (O). 

Any ECHO-type messages use the same OPCODE value as the COMMAND-type message that is being echoed. The 
DATA field of an ECHO-type message contains either the same data as sent in a COMMAND-type "WRITE" message 
or the data requested by a COMMAND-type "READ" message. 

A group of predefined OPCODES is reserved for vendor proprietary messages. 

7.5.3.1 Status messages 

Status messages are presented in table 33. 

Table 33: STATUS - type VOC Messages 



Name 


Type 


OPCODE 


DATA field 


Description 


Status 


IDLE 


STATUS 


OxFF 


0x0000 


An IDLE message. Sent by 

both VTU-O and VTU-R when 

VOC is inactive. 


M 


EGG 


STATUS 


OxFG 


eoc message 


An eoc message sent by both 

VTU-O and VTU-R when OG 

is used for eoc transport (VOG 

inactive) 


M 


UTG 


STATUS 


OxFO 


Same as the GOIVIMAND 
message being UTC'ed 


Unable-To-Gomply message. 

Sent by the VTU-R when the 

received command couldn't be 

executed by some reason 


M 


NGTE: The UTG message from the VTU-R is a valid response to a GOMMAND-type message only if support for 
that command by the VTU-R is optional. 
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7.5.3.2 



Performance-monitoring messages 



Performance -monitoring messages are intended to deliver far-end line related primitives, detected in PMD and PMS-TC 
sub-layers, and path related primitives, detected in different TPS-TC. The OPCODES from 0x90 to 0x9F are reserved 
for proprietary use. 

The following 2-bit combinations shall be used for coding of the US and DS carriers: 

• 00 - Carrier ID; 

• 01 - Carrier 2D 

• 10 - Carrier lU 

• 11 - Carrier 2U. 

For commands which deal with both carriers of the same direction only the second bit shall be set to at the transmit 
side and omitted at the receive side. 



Table 34: Performance Monitoring VOC IVIessages 



Name 


Type 


OPCODE 


DATA Field 


Description 


Status 




Line-related 


PMD 








SNR REQ 


COMMAND 


0x01 


COMMAND: 2 MSB = DS carrier 


Requests VTU-R to send 


M 




(READ) and 




code; the rest = 


the specified DS carrier 






ECHO 




ECHO: 2 MSB = DS carrier code; 
8 LSB = SNR in dB, tlie rest = 
LSB weight = 0,25 dB 


SNRindB 




SNR REP 


COMMAND 


0x02 


COMMAND and ECHO: 2 MSB = 


Send by VTU-0 to 







(WRITE) and 




US carrier code; 8 LSB = SNR in 


indicate the specified US 






ECHO 




dB, the rest = 0. 
LSB weight = 0,25 dB 


carrier SNR in dB 




ATT REQ 


COMMAND 


0x03 


COMMAND: 2 MSB = DS carrier 


Requests VTU-R to send 


M 




(READ) and 




code; the rest = 


the specified DS carrier 






ECHO 




ECHO: 2 MSB = DS carrier code; 
9 LSB = attenuation In dB, the 
rest = 
LSB weight = 0,25 dB 


attenuation in dB 




ATT REP 


COMMAND 


0x04 


COMMAND and ECHO: 2 MSB = 


Send by VTU-0 to 







(WRITE) and 




US carrier code; 9 LSB = 


indicate the specified US 






ECHO 




attenuation in dB, the rest = 0. 
LSB weight = 0,25 dB 


carrier attenuation in dB 




Reserved 


COMMAND 
and ECHO 


0x05-0x0F 











Line-related 


PMS-TC 








FECS REQ 


COMMAND 


0x10 


COMMAND: 0x0000 


Requests VTU-R to send 


M 




(READ) and 




ECHO: VTU-R fees data as a 1 6- 


the number of octets 






ECHO 




bit number of erred octets (1 ) 


corrected by PEC in the 
Slow channel since the 
last PECS_REQ 
command 




PECS REP 


COMMAND 


0x11 


COMMAND and ECHO: VTU-0 


Reports the number of 







(WRITE) and 




fees data as a 1 6-bit number of 


octets corrected by FEC 






ECHO 




erred octets (1) 


in the VTU-0 Slow 
channel since the last 
FECS REP command 




FECF REQ 


COMMAND 


0x12 


COMMAND: 0x0000 


Requests VTU-R to send 


0(2) 




(READ) and 




ECHO: VTU-R fec-fdata as a 16- 


the number of octets 






ECHO 




bit number of erred octets (1 ) 


corrected by PEC in the 
Fast channel since the 
last PECP_REQ 
command 
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Name 


Type 1 OPCODE |DATA Field 


Description 


Status 


Line-related PMD 


FECF REP 


COMMAND 


0x13 


COMMAND and ECHO: VTU-0 


Reports the number of 







(WRITE) and 




fec-f data as a 1 6-bit number of 


octets corrected by FEC 






ECHO 




erred octets (1) 


in the VTU-0 Fast 
channel since the last 
FECF REP command 




ERRS REQ 


COMMAND 


0x14 


COMMAND: 0x0000 


Requests VTU-R to send 


M 




(READ) and 




ECHO: VTU-R errs data as a 


the number of octets that 






ECHO 




16-bit number of erred codewords 

(1) 


were un-correctable by 
FEC codewords in the 
Slow channel since the 
last ERRS_REQ 
command 




ERRS REP 


COMMAND 


0x15 


COMMAND and ECHO: VTU-0 


Reports the number of 







(WRITE) and 




errs data as a 1 6-bit number of 


octets that were 






ECHO 




erred codewords (1) 


un-correctable by FEC 
codewords in the VTU-0 
Slow channel since the 
last ERRS_REP 
command 




ERRF REQ 


COMMAND 


0x16 


COMMAND: 0x0000 


Requests VTU-R to send 


0(2) 




(READ) and 




ECHO: VTU-R err-fdata as a 16- 


the number of octets that 






ECHO 




bit number of erred codewords (1 ) 


were un-correctable by 
FEC codewords in the 
Fast channel since the 
last ERRF_REO 
command 




ERRF REP 


COMMAND 


0x17 


COMMAND and ECHO: VTU-0 


Reports the number of 







(WRITE) and 




err-f6a\a as 16-bit number of 


octets that were 






ECHO 




erred codewords (1) 


un-correctable by FEC 
codewords in the VTU-0 
Fast channel since the 
last ERRF_REP 
command 




Reserved 


COMMAND 
and ECHO 


0x1 8-0x1 D 









VTUO INFO 


COMMAND 


0x1 E 


COMMAND and ECHO: first two 


Reports the VTU-0 INFO 


M 




(WRITE) and 




octets of the VTU-0 INFO data 


to the VTU-R 






ECHO 




field (note 3) 






VTUR INFO 


COMMAND 


0x1 F 


COMMAND: 0x0000 


Reports the VTU-R INFO 


M 




(READ) and 




ECHO: first two octets of the 


to the VTU-0 






ECHO 




VTU-R INFO data field (note 3) 






NOTE 1 : The e 


;rror count saturates at 65 535. 






NOTE 2: Turns 


; to mandatory if Fast channel is supported. 






NOTES: The\ 


/TUR INFO and VTUO INFO data fields carries a combination o 


f data from the modem inci 


jding the 


vend 


Dr ID, revision number and configuration registers (clause 7.7.2). 


The format of the VTUR INFO and 


VTUC 


D_INFO data fields is identical and consists of the following data: 






• 


vendor ID (4 octets); 






• 


revision number (2 octets); 






• 


spectral plan/band support (2 octets); 






• 


PSS or BSS indicator (1 octet). 






Thef 


rst two octets of the vendor ID are transferred by the command, f 


urther octets are communic 


ated 


using 


the NEXT WORD commands. 







7.5.3.3 



Configuration messages 



The configuration VOC messages are intended to configure and reconfigure the VDSL hnk by modifying its 
transmission parameters during the steady-state transmission. Two types of messages are defined for hnk configuration. 
The Parameter Setting messages (table 36) dehver the configured parameter value from the VTU-O to the VTU-R 
Activation database (clause 8.3). The Trigger messages (table 39) execute the change of link transmission parameters to 
a new setting. 
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7.5.3.3.1 



Parameter setting messages 



The VDSL link configuration is performed by setting/modification of at least one of three different STP (WS_STP, 
CR_STP or I_STP), as described in clause 8.3.2. The set of link transmission parameters (STP) is presented in table 89. 
A VOC configuration message includes the targeted upstream/downstream carrier code, the targeted STP code, and the 
applied parameter value. A PROFILE message changes the profile by switching all the parameters of the targeted STP 
at the same time to standard values, defined by a corresponding transmission profile. 

All Parameter Setting messages are of COMMAND WRITE type; the COMMAND and the ECHO DATA fields are 
equal and contains the parameter value to be set at the VTU-R. 

For any Parameter_Setting message a complimentary Read-back message of COMMAND read type could be built to 
verify the configured parameter value or read the recommended parameter value. All Read-back messages are of 
COMMAND READ type. A Read-back message shall be built from the corresponding Parameter_Setting message by 
the following rule: 

• the OPCODE of a Read-back message equals to OPCODE of the corresponding Parameter Setting Message 
increased by 0x20; 

• the DATA field of a Read-back message differs from the corresponding Parameter_Setting message by the 
parameter value only. The latest is set to zero for the COMMAND and equals to the actual parameter value 
setting at the VTU-R for the ECHO. 

The DATA field format for both Parameter_Setting and Read-back messages is presented in table 35. 

Table 35: DATA Field Format for ParameterSetting and Read-back Messages 



D15 1 D14 


D13 


D12 


D11-D0 


STP Code (1) 


US or DS 


Carrier 1 or 2 


Parameter Value 




Carrier Code (2, 3) 







NOTE 1 : The following 2-bit combinations shall be used for STP coding: 

00 - for I_STP; 

01 -forWS_STP; 
10-forCR_STP; 

11 - recommend for CR_STP. 

NOTE 2: For DS and US carriers coding shall be used the 2-bit combinations presented in clause 7.5.3.2. 

NOTE 3: For commands which deal with both carriers of the same direction only (PROFILE, INTERLV, FRAME, 
PSDMASK) bit D12 shall be set to at the transmit side and omitted at the receiving side. 

The OPCODES from 0x29 to Ox3F are reserved for proprietary use. 

The OPCODES from 0x40 to Ox5F are reserved for Readback messages. 
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Table 36: Parameter Setting Messages 



Name 


Type 


OPCODE 


Parameter Value 


Description 


Status 


PROFILE 


COMMAND 

(WRITE) and 

ECHO 


0x20 


12-bit transmission 
profile code (1) 


Selects the VTU-R 

transmission profile for 

the specified direction 

and STP 


M 


INTERLV 


COMMAND 

(WRITE) and 

ECHO 


0x21 


2 MSB = log2(S/l) or to 

disable interleaving, 

8 LSB = M (M = 

disables interleaving) 

all other bits = 


Selects the VTU-R 

interleaving depth for 

the specified direction 

and STP 


M 


FRAME 


COMMAND 

(WRITE) and 

ECHO 


0x22 


8 MSB = F, 
4 LSB = RF/2, (2) 


Selects the VTU-R 

frame format for the 

specified direction and 

STP 


M 


PSDMASK 


COMMAND 

(WRITE) and 

ECHO 


0x23 


12-bit PSD mask code, 
(3) 


Selects the VTU-R 

transmit PSD mask for 

the specified STP 


M 


PSDLEVEL 


COMMAND 

(WRITE) and 

ECHO 


0x24 


4 MSB = 0, 8 LSB = 

PSD[dBm/Hz] -1-100, LSB 

weight = 0,25 dBm/Hz 


Selects the VTU-R 

transmit PSD level for 

the specified US carrier 

and STP 


M 


PSDLEVEL_REP 


COMMAND 

(WRITE) and 

ECHO 


0x25 


4 MSB = 0, 8 LSB = 

PSD[dBm/Hz] -1-100, LSB 

weight = 0,25 dBm/Hz 


Reports the VTU-0 

transmit PSD level for 

the specified DS carrier 

and STP 





SMBLRATE 


COMMAND 

(WRITE) and 

ECHO 


0x26 


4 MSB = 0, 8 LSB = 
symbol rate profile S, (5) 


Selects the VTU-R 

symbol rate profile for 

the specified carrier 

and STP 





CONSTEL 


COMMAND 

(WRITE) and 

ECHO 


0x27 


8 MSB = 0, 4 LSB = 
logj (constellation size) 


Selects the VTU-R 

constellation size for 

the specified carrier 

and STP 





CENFREQN 


COMMAND 

(WRITE) and 

ECHO 


0x28 


2MSB = 0, 10LSB = 

centre frequency profile 

K,(6) 


Selects the VTU-R 

centre frequency 

profile for the specified 

carrier and STP 





Reserved 


COMMAND 
and ECHO 


0x29- 
OxSF 










NOTE 4: The frame format is defined by the total number of octets (F < 180) and the number of redundancy octets 
(RF < 16) in the Fast codeword. The valid nonzero values for F and RF are presented in clause 6.5.1. 

NOTE 5: The symbol rate profile is calculated as 5 = SR/BSR, where SR is the required symbol rate in kBaud and 
BSR is defined in clause 5.2.5. 

NOTE 6: The centre frequency profile is calculated as K= 2/c/BSR, where /c is the required centre frequency in 
kHz and BSR = 33,75 kBaud as defined in clause 5.2.5. 

NOTE 7: Transmission profile code bears the profile name, as defined in clause 5.2.5, in the following format: 
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Table 37: Transmission profile code 



Bit 


D11 


D10-D8 


D7-D6 


D5-D4 


D3 


D2 


D1 


DO 


Profile name 


X 


Y 


Xi 


X2 


- 


X3 


X4 


Xs 


character 


















Coding rules 


1 ^S 


001 ^A1/S1 


00^0 


00^0 


See note 


1 ^N 


1 ^A 


1 ^ VDSL 




0<^A 


010^A2/S2 

(note 9) 
011^ A3/S3 
1 00 ^ A4/S4 
110^ A2/S2 

(note 9) 

000 <r^ vendor 

proprietary 


01 ^1 
10^2 
11 ^3 


01 ^1 
10^2 
11 ^3 


8 


O^O 


O^N 


band allocation 
<-> Optional 

regional 

specific band 

allocation 



NOTE 8: The constellation size is forced to C = 4 for both carriers in both directions when the value of bit D3 = 1. 
In the PROFILE-ECHO message bit D3 may be overwritten by the VTU-R. If it is set then the VTU-R is 
only capable of operating with a fixed constellation size of 4 with the current channel conditions. 

NOTE 9: The code 1 10 shall be used for A2/S2 when the PSD mask is FTTCab variant A and code 010 shall be 
used when the PSD mask is FTTCab variant B. 

NOTE 10:The PSD mask code bears the PSD mask specification, as defined in clause 5.2.4.2, in the following 
format: 

Table 38: PSD mask code 



Bit 


D11 


D10-Dg 


D8-D6 


D5 


D4 


D3 


D2 


D1 


DO 


Parameter 


Mask 


Mask type 





notch 1 


notch2 


notch3 


notch4 


notchS 


notchS 


Coding 
rules 


0^M1 
1 ^M2 


00 ^ Pcab 
01 ^ Pex.P1 
10^Pex.P2 

1 1 ^ N/A 


N/A 


Amateur bands notches setup 
O^OFF 
1 ^ON 



NOTE 11: Default frequency values for notches 3 to 6 are defined in TS 101 270-1 [1] (first 4 rows of table 16). 
Notch 6 is the lowest frequency notch and notch 3 is the highest frequency notch within the band plan. 
Other characteristics of the notches are for further study. 



7.5.3.3.2 



Trigger messages 



All Trigger messages are of type COMMAND WRITE. Both the COMMAND and the ECHO DATA fields contain 
OxAAAA. 

Table 39: Trigger IVIessages 



Name 


Type 


OPCODE 


Description 


Status 


CHANGE 


COMMAND 

(WRITE) and 

ECHO 


OxAO 


Requests the VTU-R to be ready to change the 

CR_STP for a new parameter setting upon the 

following trigger handshake. 


M 


IDLEREQ 


COMMAND 

(WRITE) and 

ECHO 


OxA1 


Requests the VTU-R to be ready to change the 

CR_STP for l_STP upon the following trigger 

handshake. 


M 


BTSERV 


COMMAND 

(WRITE) and 

ECHO 


0xA2 


Requests the VTU-R to be ready to change the 

CR_STP for WS_STP upon the following trigger 

handshake. 


M 



£75/ 



97 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



7.5.3.4 



Control messages 



Control VOC messages are intended for system maintenance in some special cases and allow the management system to 
override some of the system routine processes. 

The OPCODES from OxE3 to OxEF are reserved for proprietary use. 

Table 40: Control Messages 



Name 


Type 


OPCODE 


DATA Field 


Description 


Status 


USPB_RESET 


COMMAND 

(WRITE) and 

ECHO 


OxEO 


COMMAND and ECHO: 

2 MSB = US carrier 

code; the rest = 


Requests VTU-R to renew 
US power back-off process 
for the specified US carrier 


M 


THRPUT 


COMMAND 

(WRITE) and 

ECHO 


OxE1 


COMMAND and ECHO: 

8 MSB = data 

throughput, 8 LSB = 

EOC throughput (0x00 = 

set, OxFF = reset) 


Sets or resets data 

throughput and EOC 

throughput at the VTU-R (1) 


M 


THRPUT_REQ 


COMMAND 

(READ) and 

ECHO 


0xE2 


COMMAND: 0x0000 

ECHO: 8 MSB = data 

throughput, 8 LSB = 

EOC throughput (0x00 = 

set, OxFF = reset) 


Requests VTU-R to send 

the status of data 

throughput and EOC 

throughput at the VTU-R 





NEXT_WORD_W 


COMMAND 

(WRITE) and 

ECHO 


0xE3 


COMMAND and ECHO: 

next two octets of data 

(note 1) 


Conveys next two octets of 

data requested by the last 

WRITE command 


M 


NEXT_WORD_R 


COMMAND 

(READ) and 

ECHO 


OxE4 


COMMAND: 0x0000 

ECHO: next two octets 

of data (note 1 ) 


Requests VTU-R to send 

next two octets of data 

requested by the last READ 

command 


M 


TX_FILTER_REP 


COMMAND 

(WRITE) and 

ECHO 


0xE5 


COMMAND and ECHO: 
4 MSB = STP code and 

carrier code, 8 LSB = 
first octet of the VTU-O 
TX FILTER register to 

be sent to the VTU-R 
(see note 2) 


Sent by the VTU-O to 
transfer the parameters of 
the VTU-O transmit filter to 
the VTU-R. This command 
shall proceed any change 

of the transmit filter 

parameters (i.e. before it 

takes effect after a restart). 


M 


TX_FILTER_REQ 


COMMAND 

(READ) and 

ECHO 


0xE6 


COMMAND: 4 MSB = 

STP and carrier code. 
ECHO: 8 MSB = 8 MSB 

of command, 8 LSB = 
first octet of the VTU-R 
TX_FILTER register to 

be sent to the VTU-O 
(see note 2) 


Requests the transfer of the 

VTU-R transmit filter 

parameters. 


M 


QUIET 


COMMAND 

(WRITE) and 

ECHO 


0xE7 


COMMAND and ECHO: 
D1 = mode of the non- 
silent transceiver, D9 = 1 
reports silenced VTU-O, 
D8 = 1 requests silent 
VTU-R, 4 LSB = 
maximum quiet period in 
seconds (max is 10) 
(see note 3) 


Requests the VTU-R to 
silence its transmitter and 
reports whether the VTU-O 

will also go silent. Either 

transmitter shall be silenced 

for the specified time period 

which starts immediately 

after the completion of the 

VOC handshake. Following 

the silent period, both 

modems enter the 

Cold-Start activation. 

(see note 4) 


M 



£75/ 



98 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



Name 


Type 


OPCODE 


DATA Field 


Description 


Status 


COPY STP 


COMMAND 


0xE8 


COMMAND and ECHO: 


Requests the VTU-R to 


M 




(READ) and 




8 MSB = source STP, 8 


copy the parameter values 






ECHO 




LSB = destination STP. 

STP encoding :- 

0x00 = CR STP; 

0x01 = DF STP; 

0x02 = WS STP; 

0x03 = WR STP; 

0x04 = RE STP; 

0x05 = l_STP; 

OxFF = all STP except 

DF STP 


from the specified source 

STP to the specified 
destination STP. (DF_STP 
is allowed only as a source) 




Reserved 


COMMAND 
and ECHO 


0xE9-0xEF 










NOTE 1: Transmission of the NEXT_WORD_R and NEXT_WORD_W commands always refers to the last VOC 
opcode (other than NEXT_WORD_W/R and IDLE) which was successfully communicated by the VOC. 
If the last opcode (other than NEXT_WORD_R and IDLE) that was successfully communicated was a 
READ command, subsequent NEXT_WORD_R commands shall transfer the next two octets of data from 
the VTU-R. If the last opcode (other than NEXT_WORD_W and IDLE) that was successfully 
communicated was a WRITE command, subsequent NEXT_WORD_W commands shall transfer the next 
two octets of data to the VTU-R. NEXT_WORD_R or NEXT_WORD_W commands which attempt to 
read or write beyond the end of the data field length defined for that command shall get a UTC response 
from the VTU-R. Receipt of a new opcode other than NEXT_WORD_RAV or IDLE by the VTU-R shall 
terminate the processing of the previous command. Receipt of a single NEXT_WORD_R/W which does 
not correspond with the preceeding command (either NEXT_WORD_R following a WRITE command or 
vice-versa) shall get a UTC response from the VTU-R. 

NOTE 2: The TX_FILTER command communicates the parameters of the transmit filter corresponding to the 
selected STP and carrier. The first octet of TX_FILTER is the number of octets to be sent or received 
using NEXT_WORD commands. 

NOTE 3: Bits D8 and D9 of the data field specify that one or both modems shall silence their transmitters for the 
quiet period specified by bits D3-D0. If both modems are silenced, after the specified time period both 
modems will initiate Cold-Start activation. If only one modem is silenced, the other modem shall 
continue to transmit as it was before the command (DIO = 0) or may transmit any other signal that 
complies with the PSD limits (DIO = 1), excluding the QUIET signal. 

NOTE 4: The non-silent modem can request to terminate the quiet period at any time by transmitting the QUIET 
signal for at least 100 ms followed by DF_STP, thereby initiating Cold-Start activation. The silent 
modem may remain so until the specified time period has elapsed or it can optionally terminate the quiet 
period early once it has detected the DF_STP signal at its receiver. 

7.6 VDSL embedded operations channel (eoc) 

The embedded operation channel {eoc) is intended to exchange system management data and control traffic between the 
VTU-O and VTU-R. The data exchanged includes system-related primitives, performance parameters, test parameters, 
configuration and maintenance commands. The eoc can provide both "internal" management functions to support the 
VDSL transceiver and a clear management channel between the VTU-O and VTU-R. 

The "internal" eoc channel, except where specified, works in bi-directional mode using an echoing protocol. Both 
transmission directions are necessary to provide full communication over the eoc. 
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7.6.1 eoc functional model 

The eoc functional model is presented in figure 48. The eoc traffic between the VTU-O and VTU-R may include either 
internal eoc traffic (originated in the VTU-O) or external eoc traffic, delivered through the external Q interface. The 
VTU-O Management Entity (VME_0) multiplexes the internal and the external traffics into an eoc information stream. 
The stream is formatted and presented at the Y_0 interface to be sent transparently over the VDSL link to the VTU-R 
Management Entity (VME_R). 

The Management Information Base (MIB) contains all the management information related to the VDSL link. It may be 
implemented as either a part of the VTU-O or as a common base shared between several VTU-O. In the first case the 
Network Management Agent (located outside of the VTU-O) accesses the MIB via the Q-interface and shall be 
supported by the VME_0. If the MIB is shared then the VME_0 accesses the MIB directly or, if necessary via the 
Q-interface. At the VTU-R the MIB and external interface support are optional. 

7.6.2 VME functionality 

VME shall provide at least the following management functions over the VDSL link: 

• Performance management; 

• Configuration management; 

• Fault management; 

• Support of the external interface (Q-interface) and MIB interface. 

NOTE: This part of VME functionality is beyond the scope of the present document. 

The VME provides management functions at the remote end via eoc in accordance with table 28 and clauses 7.3.2, 
7.3.3, 7.3.5 and 7.3.6. 



Ext_OAM_R interface 



MIB 



Y R interface 



EIA 
.... 
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<;=> VMER 



t 
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TPS-TC 
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PMS-TC 



U R 



Q interface (CMIP) 



EIA 



VME_0 



OAM Data, 
Commands 



t 
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PMD&TC 
Management 



TPS-TC 
OC 



U O 



PMS-TC 



1 




1 


PMD 




PMD 






MIB 



Y^O interface 



MIB - Management Information Data Base 
VME - VDSL Management Entity 
EIA - External Interface Adapter 

Figure 48: eoc functional model 

The VME shall also provide the following eoc-related functionality: 

• Support of the eoc protocol at the y-interface. 

• Multiplexing/de -multiplexing of the internal and external eoc traffic. 
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7.6.3 eoc protocol format 



The same eoc protocol format shall be used at both sides of the link. The eoc protocol format shall implement the 
HDLC protocol as defined in ITU-T Recommendation G.997.1 [8]. The use of the information payload of the HDLC 
frame is defined in the following clauses. 

Within the HDLC protocol the VME shall multiplex internal eoc and external messages received via the Q-interface. 
All external messages to be transported over the VDSL link shall have an HDLC address field value of OxFF. The 
internal eoc messages may use an HDLC address field with a value of OxlL Other address field values are for further 
study. 

NOTE: In the rest of this clauses the term "eoc" is used to refer to the internal eoc except where indicated. 

7.6.3.1 External message format 

The information payload of the HDLC frame carrying an external message shall not exceed 510 octets. The external 
message encapsulation method and the contents of external messages are beyond the scope of the present document. 

7.6.3.2 Internal message format 

The information payload of the HDLC frame carrying an internal message (further called "eoc message") shall contain 
at least 2 octets sent from the VME_0 to the VME_R and vice versa. Use of internal messages with more than two 
octets is for further study (the number of octets shall always be even). 

7.6.3.3 eoc organisation and message types 

The eoc allows the VTU-O (acting as master) to invoke certain management functions at the VTU-R by sending eoc 
command messages. The VTU-R (acting as slave) shall acknowledge a command message it has received without error 
by sending a response eoc message and perform the requested function. However, autonomous messages may be sent 
from the VTU-R independently (as soon as the appropriate data is available) but not as a response on a VTU-O 

message. 

There are three types of eoc messages: 

• bi-directional messages (d/u): these are originated by the VTU-O, and echoed by the VTU-R to indicate the 
correct reception of each message; 

• downstream messages (d): these are originated by the VTU-O and acknowledged by the VTU-R; 

• upstream messages (u): these are originated by the VTU-R and may be in response to a downstream message 
or autonomous. 

NOTE: Acting as a master, the VTU-O usually determines the rate of the eoc communication, as the VTU-R 
responds with only one message on each received eoc message. 
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7.6.3.3.1 



eoc message structure 



The 16 bits of an eoc message are partitioned among six fields, which are summarised in table 41 and defined in the 
following clauses. 

NOTE: Only the first 13 MSB of the 2-octet eoc data shall be used for the eoc message starting from Bit#l. The 
last three LSB shall be reserved. 

Table 41 : eoc Message Fields 



Field # 


Bit# 


Description 


Notes 


1 


1-2 


ADDRESS field 


Can address up to 4 locations 


2 


3 


DATA (0) or OPCODE (1) field 


Data used for both read and write 


3 


4 


PARITY field 
Odd (1) or even (0) 


Octet order indication for multi-octet 
transmission 


4 


5 


MESSAGE/RESPONSE field 
Message/Response (1) or Autonomous 
message (0) 


Currently autonomous messages are 
defined for the VTU-R only 


5 


6-13 


INFORMATION field 


One out of 58 opcodes or 8 bits of 
data 


6 


14-16 


Reserved 


For further use 



7.6.3.3.1.1 ADDRESS field (#1) 

The two bits of the address field can address up to four locations. Only two locations are presently defined: 

• 00: VTU-R address; 

• 01: Reserved for future applications; presently invalid; 

• 10: Reserved for future applications; presently invalid; 

• 11: VTU-O address. 

The VTU-O shall address messages to the VTU-R by setting the ADDRESS field equal to the VTU-R address (00). 
When responding to a message received from the VTU-O, the VTU-R shall keep the ADDRESS field equal to the 
VTU-R address (00). The VTU-R shall set the ADDRESS field equal to the VTU-O address (11) only when sending an 
autonomous message to the VTU-O. 



7.6.3.3.1.2 



DATA or OPCODE field (# 2) 



This field is set to false (0) when the information field of the eoc message contains a data octet and is set to true (1) 
when it contains an opcode. 



7.6.3.3.1.3 



PARITY field (# 3) 



This bit helps to speed up the multi -octet reads and writes of data by eliminating the intermediate messages to indicate 
to the far end that the previous octet was successfully received. 

For the first octet of the sent read/write data, this bit shall be set to true (1) to indicate "odd" octet. For the next octet, it 
shall be set to false (0) to indicate "even" octet and so on, alternately. 

The PARITY field shall always be set to 1 if the information field carries an opcode different from the "Next Octet" 
opcode. If a "Next Octet" opcode is applied, the PARITY field is toggled for multi-octet data transfer. 



7.6.3.3.1.4 



MESSAGE/RESPONSE field (# 4) 



When set to true (1) this field indicates that the current eoc message is an eoc command message or an eoc response 
message (echo); a false (0) value indicates that it is an autonomous message. 

NOTE: For the VTU-O this field shall always be set to true. For the VTU-R this field shall also be set to true 
except the autonomous messages. 
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7.6.3.3.1.5 INFORMATION field (#5) 

Up to 58 different 8-bit opcodes or an 8-bit data value may be transported in the information field. 

The opcode set is restricted to codes that provide a minimum Hamming distance of 2 between all opcodes, and a 
minimum distance of 3 between certain critical codes and all other codes. 



7.6.3.3.2 



eoc Message Set 



The VTU-O shall send command messages to perform certain functions at the VTU-R. Some of these functions require 
the VTU-R to activate changes in the circuitry (e.g. to send corrupted CRC/FEC bits). Other functions are to read from 
and to write into the MIB data registers at the VTU-R. These functions are used by the VTU-O to read the VTU-R 
status or performance parameters, or for limited maintenance extensions to the service modules. 

Some of eoc commands are "latching", meaning that a subsequent eoc command shall be required to release the VTU-R 
from that state. Thus, multiple VDSL eoc-initiated functions can be in effect simultaneously. To maintain the latched 
state, the command "Hold State" shall be sent. 

A command, "Return-To-Normal", is used to unlatch all latched states. This command is also used to bring the VDSL 
system to the Idle state, when no eoc command is active in the VTU-R. 

All the eoc messages and their opcodes are summarised in table 42. 

Table 42: The eoc Message Set List 



Opcode (HEX) 


OPCODE meaning 


Direction 


Abbreviation and notes 


01 


Hold state 


d/u 


HOLD 


FO 


Return-To-Normal 


d/u 


RTN 


02 


Perform "self-test" 


d/u 


SLFTST 


04 


Unable-to-comply 


u 


UTC 


07 


Request for corrupted CRC/FEC 


d/u 


REQCOR (latching) 


08 


Request end of corrupted CRC/FEC 


d/u 


REQEND 


OB 


Notify corrupted CRC/FEC 


d/u 


NOTCOR (latching) 


OD 


Notify end of corrupted CRC/FEC 


d/u 


NOTEND 


OE 


End of data 


d/u 


EOD 


10 


Next octet 


d 


NEXT 


13 


Request test parameters update 


d/u 


REQTPU 


14 


Error 


d/u 


ERR 


20, 23, 25, 26, 
29, 2A, 2C, 2F, 
31,32,34,37, 
38, 3B, 3D, 3E 


Write data register. Register 

number specified by opcode value 

(e.g. opcode 0x23 specifies register 

1, see table 43). 


d/u 


WRITE 


40, 43, 45, 46, 
49, 4A, 4C, 4F, 
51,52,54,57, 
58, 5B, 5D, 5E 


Read data register. Register 

number specified by opcode value 

(e.g. opcode 0x45 specifies register 

2, see table 43) 


d/u 


READ 


19, 1A, 1C, IF 


Vendor proprietary protocols 


d/u 


Four opcodes are reserved 
for vendor proprietary use. 


15, 16,80,83, 

85, 86, 89, 8A, 

8C, 8F 


Undefined codes 




These codes are reserved 

for future use and shall not 

be used for any purpose. 



NOTE 1: The Opcode values are given as MSB left, LSB right with the MSB mapping to the eoc bit 13 and the 
LSB to the eoc bit 6. 

NOTE 2: The given Opcode values guarantee a minimum Hamming distance of: 

2 - between all opcodes (by requiring odd parity for all but two critical codes); 

3 - between the "Return to Normal" (or "idle") code and all other codes. 
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7.6.3.3.3 Bi-directional eoc messages 

Each bi-directional message sent by the VTU-O shall be echoed by the VTU-R if received correctly. The following 
messages are specified as bi-directional (with their abbreviated names and hex opcodes in parentheses): 

• Hold State: (HOLD, 0x01) This message tells the VME-R to maintain the VTU-R eoc processor and any 
active VDSL eoc-controUed operations (such as latching commands) in their present state; 

• Return to Normal (Idle Code): (RTN, OxFO) This message releases all outstanding eoc-controlled operations 
(latched conditions) at the VTU-R and returns the VDSL eoc processor to its initial state.; 

• Request Corrupt CRC/FEC: (REQCOR , 0x07) This message requests the VTU-R to send corrupt CRC/FEC-s 
to the VTU-O until cancelled by the "Request End of Corrupt EEC" or "Return-To-Normal" message. In order 
to allow multiple VDSL eoc-initiated actions to be in effect simultaneously, the "Request corrupt EEC" 
command shall be latching; 

• Request End of Corrupt CRC/FEC: (REQEND, 0x08) This message requests the VTU-R to stop sending 
corrupt CRC/EEC-s toward the VTU-O; 

• Notify Corrupted CRC/FEC: (NOTCOR, OxOB) This message notifies the VTU-R that intentionally corrupted 
CRC/EEC-s will be sent from the VTU-O until cancellation is indicated by "Notify End of Corrupted 
CRC/FEC"; 

• Notify End of Corrupted CRC/FEC: (NOTEND, OxOD) This message notifies the VTU-R that the VTU-O has 
stopped sending corrupted CRC/FEC-s; 

• Perform Self-Test: (SLETST, 0x02) This message requests the VTU-R to perform a self-test. The result of the 
self-test shall be stored in a register at the VTU-R. After the VTU-R self test, the VTU-O reads the test results 
from the VTU-R register. This is for further study; 

• Receive/Write Data (Register #): (WRITE, see clause 7.6.3.5.3.2) This message directs the VTU-R to enter the 
Data Write Protocol state, receive data, and write it in the register specified by the opcode; 

• Read/Send Data (Register #): (READ, see clause 7.6.3.5.3. 1) This message directs the VTU-R to enter the 
Data Read Protocol state, read data from the register specified by the opcode, and transmit it to the VTU-O; 

• End of Data: (EOD, OxOE). This message is sent by the VTU-O after it has sent all octets of data to the 
VTU-R. The message is send by the VTU-R in either of the following cases: 

in response to a "Next Octet" message from the VTU-O that is received after all octets have been read 
from the currently addressed VTU-R register; 

in response to a message from the VTU-O that contains a data octet after all octets have been written to 
the currently addressed VTU-R register. 

• Vendor Proprietary Opcodes: (VPC, 0x19, 0x1 A, OxlC, OxlF). Four opcodes have been reserved for vendor 
proprietary use. The VTU-O shall read the Vendor ID code register of the VTU-R to ensure compatibility 
between the VTU's before using proprietary opcodes; 

• Request Test Parameters Update: (REQTPU, 0x13). This message requests the VTU-R to update the test 
parameters set as defined in clause 7.3.6. Test parameters supported by the VTU-R shall be updated within 
10 s after the request is received. Updated test parameters may be read by the VTU-O thereafter; 

• Error: (ERR, 0x14). This message requests the VTU-O or VTU-R to repeat the last message. The message is 
send after a non-correctable error has been detected in the received HDLC frame. 

7.6.3.3.4 Downstream messages 

There is one message that may be sent only by the VTU-O: 

• Next Octet: (NEXT, 10) This message is sent repeatedly by the VTU-O (toggling bit four for multi-octet data 
until all data has been sent) while it is in Data Read protocol state. The message is echoed by the requested 
octet of the VTU-R data with toggling of the bit four for multi-octet data or by the End-of-Data message. 
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7.6.3.3.5 Upstream messages 

The messages that may be sent only by the VTU-R are: 

• Unable-to-Comply (UTC): (UTC, 04), acknowledgement. The VTU-R shall send this message when it 
receives a command eoc message that it cannot perform for either reason: 

it does not recognise the command; 

it cannot implement the command; 

the command is unexpected for the current state of the eoc protocol. 

• Autonomous messages: for further study. All autonomous messages have bit 5 set to and bit 3 set to 1 to 
indicate that the message contains an opcode. The information field shall contain the opcode of the 
corresponding message (table 42). 

7.6.3.4 VTU-R Data Registers 

The VTU-R data registers shall be defined as: 

• VTU-R Vendor ID code (4 octets): The format of the VTU-R Vendor ID code is for further study. 

• VTU-R Revision number. The VTU-R Revision Number register shall be at least one octet long; longer 
registers shall be vendor discretionary. The most significant bit of the VTU-R Revision number definition is 
for further study. 

• VTU-R Serial number (32 octets): The format of the VTU-R Serial Number shall be vendor discretionary. 

• Self Test Results: The most significant octet of the Self -Test Results shall be 0x00 if the self test passed, and 
0x01 if it failed (the meaning of "failure" is vendor discretionary); other values are reserved for future use. The 
length and syntax of the remainder shall be vendor discretionary. 

• Line attenuation (1 octet): The line attenuation is defined in clause 7.3.6.2. 

• SNR Margin (1 octet): The SNR margin is defined in clause 7.3.6.2. 

• VTU-R configuration (>30 octets): The VTU-R configuration registers may contain data for both TPS-TC 
sub-layer, and application layer and external service module configuration. For further study. 

NOTE 1: The VDSL link configuration (applied for the PMD and PMS-TC sub-layer) is delivered by the VOC. 
Table 43 summarises the VTU-R data registers and their applications. 

Table 43: VTU-R Data Registers 



REG # (HEX) 


USE 


LENGTH 


DESCRIPTION 





Read 


4 octets 


VTU-R vendor ID 


1 


Vendor discretionary 


VTU-R revision number 


2 


32 octets 


VTU-R serial number 


3 


Vendor discretionary 


Self test results 


4 


Read/Write 


Vendor discretionary 


Vendor discretionary 


5 


Vendor discretionary 


Vendor discretionary 


6 


Read 


4 octets 


Line attenuation 


7 


4 octets 


SNR margin 


8 


> 30 octets 


VTU-R Configuration 


9-F 


reserved 


reserved 


For future use (see note 2) 


NOTE 1 : Registers shall be read MSB first. 

NOTE 2: The VTU-R shall respond UTC if requested to write Into one of these registers. 
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7.6.3.5 eoc protocol states 

7.6.3.5.1 Message/echo-response protocol state (idle state) 

To initiate an action at the VTU-R, the VTU-O shall begin sending eoc messages with the Data/Opcode set to true and 
with the appropriate message opcode in the information field. The VTU-R shall initiate the action only when an 
error-free and properly addressed eoc message has been received. The VTU-R shall respond to all the received 
messages. If either the VTU-R or VTU-O detects a non-correctable error in the received HDLC frame it shall send the 
corresponding Error message. The combination of the VTU-O sending a message and the VTU-R echoing the message 
back comprises the message/echo-response protocol state. 

NOTE 1 : The time it takes to complete an eoc message transmission under both error and error-free conditions will 
depend on the vendor's implementation. 

NOTE 2: If the eoc message was one of the latching commands, then the VTU-R shall maintain the condition until 
the VTU-O issues the appropriate command to end the specific latched condition or until the VTU-O 
issues the "Return-to-Normal" command. 

7.6.3.5.2 Message/unable-to-comply response protocol state (UTC state) 

When the VTU-R does not support the function requested by a message that it has properly received, it shall respond 
with the UTC message with its own address and switch to the UTC state. 

The reception by the VTU-O of a properly addressed UTC message constitutes notification to the VTU-O that the 
VTU-R does not support the requested function. 

7.6.3.5.3 Message/data-response protocol state 

The VTU-O may either write data into, or read data from the VTU-R MIB memory. 

7.6.3.5.3.1 Data read protocol 

To read data from the VTU-R, the VTU-O shall send a "Send Data" opcode message to the VTU-R that specifies the 
register to be read. After receiving the acknowledgement, the VTU-O shall request the first octet to be sent from the 
VTU-R by sending "Next Octet" message with bit four set to true, indicating a request for an "odd" octet. The VTU-R 
shall respond to this "Next Octet" message by sending the first octet of the requested data in the information field of an 
eoc message with bit four set to true to indicate "odd octet" and with bit 3 set to false to indicate the eoc data message. 
If there is more data to be read, the VTU-O shall request the second octet of data by sending "Next Octet" messages 
with bit four set to false ("even octet"). The VTU-R responds to the message by sending eoc message containing the 
second octet of the register with bit four set to "even octet". The process continues for the third and all subsequent octets 
with the value of bit four toggling from "odd octet" to "even octet" or vice versa, on each succeeding octet. Each time 
bit four is toggled, the VTU-R responds by sending the next data octet. The process ends only when all of the requested 
data in the register are read. 

To continue reading data, once the VTU-R is in the Data Read odd or even State, the only message that the VTU-O is 
allowed to send is "Next Octet" with bit four toggling. To end the data read mode abnormally, the VTU-O sends either 
"Hold State" or "Return-to-Normal", depending on whether any latched states are to be retained. If the VTU-R receives 
any other message while it is in Data Read odd or even State, it shall go into the UTC State. 

If, after all octets have been read from the VTU-R register, the VTU-O continues to send the "Next Octet" message with 
bit four toggled, then the VTU-R shall send an "End-of-Data" message. 

For the VTU-O, the data read mode ends either when the VTU-O has received the last requested data octet or when the 
VTU-O has received "End-of-Data" message. The VTU-O shall then switch both itself and the VTU-R into the Idle 
State (by sending a "Hold State" or a "Return-to-Normal" message), and the VTU-R shall release the register and leave 
the Data Read State after receiving either "Hold State" or "Return-to-Normal" message. 
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7.6.3.5.3.2 Data write protocol 

To write data into the VTU-R MIB memory, the VTU-O shall send a "Write Data" opcode message to the VTU-R that 
specifies the register to be written to. When the VTU-R acknowledges (echoing), the VTU-O sends the first octet of 
data. The VTU-R shall acknowledge the receipt of the octet with an echo of the message. After the VTU-O receives the 
echo response, it shall send the next octet of data. Each time the VTU-O receives echo response, it shall switch to 
sending the next octet of data. It shall also toggle the "odd/even" bit accordingly. ("Next Octet" messages are not used 
in the Data Write mode). The VTU-O shall end the write mode with the "End of Data" message indicating to the 
VTU-R to release the register and return to the Idle State. 

To continue writing data once the VTU-R is in the Data Write odd or even state, the only message that the VTU-O is 
allowed to send is the "Data Octet" message with bit 3 set to false and with bit four toggling. To end the Data Write 
state abnormally, the VTU-O may switch to the " End-of-Data" message. If the VTU-R receives any other message 
while it is in Data Write state, it shall go into the UTC state. 

If, after all octets have been written to the VTU-R register, the VTU-O continues to send the data, then the VTU-R shall 
send an "End-of-Data" message. 

7.7 Single carrier specific OAIVI objects 
7.7.1 Line related primitives 

7.7.1 .1 Near-end defects 

• Loss-of-carrier (los_cr) defect occurs when the received carrier signal power, averaged over a 0,5 s period, is 
lower than the set threshold. It terminates when the signal power exceeds the set threshold. 

• Loss-of-signal (los) defect occurs when the los_cr defect occurs for any of the carriers specified by the 
applicable transmission profile. It terminates when loc_cr for all carriers is cleared. 

7.7.1 .2 Far-end defects 

• Far-end loss-of-carrier (flos_cr) defect occurs when a los_cr defect is reported in four or more out of six 
contiguous received far-end indicator reports. The flos_cr is terminated when less than two far-end los_cr 
indicators are reported out of six contiguous received far-end indicator reports. 

• Far-end loss-of-signal (flos) defect occurs when aflos_cr defect is reported for any carrier specified by the 
applicable transmission profile. It terminates whenflos_cr for all carriers is cleared. 



£75/ 



107 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



7.7.2 VTU-R configuration register 

The register consists of 57 octets and shall include the data specified in table 44. 

Table 44: VTU-R configuration register 



Octet number (hex) Parameter description Format 


Line-related 


0x00-0x01 


Profile 


PROFILE command, table 36 


0x02-0x03 


Transmit PSD limit 


PSDMASK command, table 36 


0x04-0x05 


Frame configuration 


FRAIVIE command, table 36 


0x06-0x07 


Symbol rate, carrier US1 


SIVIBLRATE command, table 36 


0x08-0x09 


Symbol rate, carrier US2 


OxOA-OxOB 


Symbol rate, carrier DS1 


OxOC-OxOD 


Symbol rate, carrier DS2 


OxOE-OxOF 


Constellation, carrier US1 


CONSTEL command, table 36 


0x10-0x11 


Constellation, carrier US2 


0x12-0x13 


Constellation, carrier DS1 


0x14-0x15 


Constellation, carrier DS2 


0x16-0x17 


Centre frequency, carrier US1 


CENFREQN command, table 36 


0x18-0x19 


Centre frequency, carrier US2 


OxIA-OxlB 


Centre frequency, carrier DS1 


OxIC-OxlF 


Centre frequency, carrier DS2 


0x40-0x41 


Interleaver configuration 


INTERLV command, table 36 


0x42-0x43 


Spectral plan/band support 


See note 1 


0x44-0x45 


Transmit PSD level, carrier US1 


PSDLEVEL command, table 36 


0x46-0x47 


Transmit PSD level, carrier US2 


0x48-0x49 


Transmit PSD level, carrier DS1 


0x4A-0x4B 


Transmit PSD level, carrier DS2 


0x4C-0x4F 


reserved 


OxFF 


Path-related 


0x20 


TPS-TC configuration 


See note 2 


0x21 


reserved 


OxFF 


0x22-0x23 


ATIVI-TC configuration 


For further study 


0x24-0x25 


STIVI-TC configuration 


For further study 


0x26-0x27 


PTIVI-TC configuration 


For further study 


0x28-0x2F 


reserved 


OxFF 


System-related 


0x30-0x33 


Vendor ID 


See note 3 


0x34-0x35 


Revision number 




0x36 


PSS or BSS flag 


OxOF = PSS, 0x00 = BSS 


0x37-0x3F 


reserved 


OxFF 


NOTE 1 : The spectral plan code format shall be as defined in table 45, the band support code format shall be as 
defined in table 46. A value of 1 indicates support for the specified spectral plan or band, a value of 
indicates no support. 

NOTE 2: Bits DO (LSB) and D1 relate to the ATIVI-TC, bit D2 is reserved, bits D3 and D4 relate to the STM-TC, bit 
D5 is reserved, bits D6 and D7 (IVISB) relate to the PTM-TC. The bits use the following coding: 

00 - not installed; 

1 1 - installed and active; 
10 - installed and disabled; 

01 - invalid option. 

NOTE 3: Use the standard 4-octet coding for vendor ID. 



Table 45: Spectral plan support code 



D7 (MSB) 


D6 


D5 


D4 


D3 


D2 


D1 


DO (LSB) 










FTTCab 

variant 

B 


FTTCab 

variant 

A 


VDSL band 
allocation 


Optional regional 
specific band allocation 
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Table 46: Band support code 



D7 (MSB) 


D6 


D5 


D4 


D3 


D2 


D1 


DO (LSB) 


- 


- 


2U 


2D 


1U 


1D 


25-138 kHz DS 


25-138 kHz US 



7.7.3 VTU-R performance registers 

The registers shall include the data specified in table 47. 

Table 47: VTU-R performance registers 



Octet number (hex) 


Parameter description 


Format 


Loop attenuation register 


0x00 


Carrier DS1 


See clause 7.3.6 


0x01 


Carrier DS2 


0x02 


Carrier US1 


0x03 


Carrier US2 


0x04 


Electrical length, US 


0x05 


Electrical length, DS 


SNR margin register 


0x00 


SNR, carrier DS1 


See clause 7.3.6 


0x01 


SNR, carrier DS2 


Self-test results register 


OxOO-OxOF 


Reserved 


OxFF 


Reserved register 


OxOO-OxOF 


Reserved 


OxFF 



7.7.4 VTU transmit filter register 

The transmit filter register at both the VTU-O and VTU-R shall include the data specified in table 48. The data only 
relates to the section of filtering operating at the symbol rate. 

Table 48: Transmit filter register 



Octet number (hex) 


Parameter description 


Format 


0x00 


Length of the register, L in octets 


0x01 to OxFF, see note 1 


0x01 


Number of zeros, NZ 


See note 2 


0x02-0x03 


First zero, real part 


0x04-0x05 


First zero, imaginary part 


0x06-0x07 


Second zero, real part 


0x08-0x09 


Second zero, imaginary part 






(4A/Z-2)-(4A/Z-1) 


Last zero, real part 


(4A/Z)-(4A/Z+1) 


Last zero, imaginary part 


{4NZ+2)-{4NZ+3) 


First pole, real part 


{4NZ+4)-{4NZ+5) 


First pole, imaginary part 






(4{NZ+NF) - 2)-{4{NZ+NP) - 1) 


Last pole, real part 


(4{NZ+NP))-{4{NZ+NP) + 1) 


Last pole, imaginary part 


NOTE 1 : The length of the register, L, equals the total number of octets required to specify A/Z zeros and NP 

poles. L = 4{NZ+NP)+2. If the parameters of the filter are not available, the value of L shall be set to zero. 

NOTE 2: The real and imaginary parts of the poles and zeros shall be represented by 16-bit, 2's compliment 
numbers scaled such that 2^" corresponds to a value of 1 . 
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8 



Link activation and de-activation 



8.1 Link state and timing diagram 
8.1.1 Overview 

Activation and deactivation may be the result of a command from network management, autonomous action caused by 
transmission anomalies or application/removal of power. Where connection information is available activation may be 
linked to transitions in the connection state. Connection information is not applicable to SDH applications and is not 
currently supported by ATM applications. Further developments are expected to enable the transmission performance 
advantages for VDSL to be exploited by ATM applications. 

During the initial installation or upon demand of the network operator the start-up of a VDSL transceiver may be 
subject to an installation procedure. This may be needed to check the spectral compatibility of the transceiver. Such a 
test procedure is for further study. 

The activation procedures begin following a successful initial installation. Three activation procedures shall be 
supported: Cold start, Resume on error, and Warm start. In addition to the three activation procedures, a de-activation 
procedure and a power-down procedure shall be supported. 

The various required and optional activation, steady state, and de-activation states and procedures are illustrated in 
figure 49. 



Management command ? 




, Dynamic » 
I Power Save ' 
N (Optional) ^ 



Figure 49: Activation/de-activation state and timing diagram 



8.1.2 Activation procedures 



8.1.2.1 



Cold start 



Cold start occurs when power is first applied to the transceiver after intrusive maintenance or if there has been 
significant change in line characteristics (for example, due to thermal effects). Cold start also occurs when transmission 
rates and other transmission parameters (such as noise margin, spectral masks, class of service, etc.) are altered. The 
duration of the cold start phase shall be less than 30 s. 



£75/ 



110 ETSI TS 101 270-2 V1.2.1 (2003-07) 



8.1.2.3 Warm start 



Warm start occurs when both transceivers start from the power down state. Power down is reached after a transceiver 
has its AC power removed on purpose (by the customer) via the power down procedure. Warm start occurs only if there 
have been few or no changes in hne characteristics. This procedure may also apply when there is an accidental AC 
removal or failure at the customer, provided the transceiver can store all necessary data and parameters to avoid the cold 
start. The duration of the warm start procedure shall be less than 5 s. 

8.1 .2.4 Resume on error 

Resume on error is the start-up process that applies to transceivers that lose synchronisation during steady state 
transmission, such as after a large impulse hit or an interruption longer than the specified micro-interruption. Resume on 
error applies only if there have been no changes in line characteristics, and if the clock-frequency recovery circuits can 
still predict the sample timing. Events leading to loss of synchronisation are longer than a micro-interruption (> 10 ms) 
and relate to the loss of frequency lock. Completion of the resume on error procedure shall require less than 300 ms. 

8.1.2.5 Warm resume 

A warm resume is the start-up process that applies to transceivers that after having achieved synchronisation have 
subsequently responded to a deactivation request. A warm resume is the usual method of activating the VDSL 
transmission system on receipt of a first incoming or outgoing broadband call request. Warm resume can only be 
initiated after a de-activation procedure such as the power saving state that keeps both LT and NT VDSL transceivers in 
a power-saving sleeping mode. A warm resume shall take place in less than 100 ms. 

Following completion of one of the activation states, steady-state transmission is achieved. 

8.1.3 Steady-state transmission 

A transceiver supporting steady-state transmission has completed all start-up processes, including full clock and frame 
synchronisation. Steady-state also implies that DSP filter adaptations have been completed. 

8.1.4 De-activation procedures 

8.1.4.1 Introduction 

De-activation is the process that places the VDSL transceiver into a power-saving state to reduce ONU heat dissipation 
and reduce unwanted RF emissions. Both the UNI and the network side must confirm that the VDSL transmission has 
stopped. De-activation assumes that all broadband traffic has ceased and all calls are closed. 

8.1.4.2 Void 

8.1.4.3 Power-down procedure 

The power-down procedure takes fully operational transceivers at the VTU-O and VTU-R to a power-down state. It can 
be used when the customer wants to turn off the transceiver AC power, or when the LT cannot support any other 
power-saving deactivation. To support the use of the normal start activation procedure, VDSL transceivers engaged in 
the power-down procedure might store transmission-related data such as equaliser states, line characteristics and 
service-related parameters. 

8.1 .4.4 Hot resume procedure 

Hot resume is the implied immediate power-on procedure to resume transmission whenever the VDSL transceiver 
alternates between steady state and the optional dynamic power save state. 
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8.1 .5 De-activated power-saving state 

This places the digital transmission system in a low power consumption mode when no calls are in progress. The NT 
and LT consume less power but are capable of detecting a wake up signal from the network side and/or from the UNI 
and executing a warm resume. When enabled by the Network Management System, this state may be entered 
automatically after a programmable time following the last broadband call. While in this state the transceivers could 
continue some (modulation-dependent) form of synchronisation on some of the following levels: clock-sync, 
frame-sync, equaliser checking and trimming, etc. 

8.1 .6 Power-down state 

The power-down state follows full removal of power at the NT or LT, or the state at the LT when the de-activated 
power saving state cannot used and VDSL transmission must be halted, such as for maintenance (hardware and/or 
software). 

8.1 .7 Dynamic power-save state 

The optional dynamic power-save state is intended to reduce the overall power consumption of the VDSL LT 
transceiver and to reduce the crosstalk level and RF egress from the VDSL system. It may be used when ATM or some 
other application links are active but not consuming the full bandwidth of the VDSL link. The dynamic power-save 
state alternates with steady state transmission. No loss of application data shall be tolerated when the VDSL transceiver 
alternates between steady-state transmission and dynamic power-save state. Support of the dynamic power-save state 
requires the support of the hot resume procedure. 



8.2 



Mu It! -carrier activation/de-activation 



8.2.1 Overview 

Initialisation of a VTU-OA'^TU-R pair includes a variety of tasks. The set of tasks is: 

• Definition of a common mode of operation; 

• Synchronisation (sample clock alignment and symbol alignment); 

• Transfer of frequency band allocation and PSD mask information from the VTU-O to the VTU-R; 

• Channel identification; 

• Noise identification; 

• Calculation of bit and energy tables; 

• Exchange of parameters (RS settings, interleaver parameters, VOC settings, bit loading and energy tables). 

Information such as PSD mask, frequency band allocation, HAM & RFI bands, bit rate symmetry ratio are initially 
available at the VTU-O side. The initial value of the cyclic extension is set during handshake and the initial value for 
the timing advance is set to the default value corresponding to a loop length of 1,5 km. 

The time line in figure 50 provides an overview of the initialisation protocol. Following the initial handshake procedure, 
a full duplex link between the VTU-O and the VTU-R is established. During the training phase, timing advance and 
upstream power back-off shall be refined. During the channel analysis & exchange state, the two modems measure the 
characteristics of the channel and agree on a contract that thoroughly defines the communication link. 

VTU-O 



Activation: l-landshal<e procedures 
(clause 8.2.3) 


Training 
(clause 8.2.4) 


Channel analysis and Exchange 
(clause 8.2.6) 



VTU-R 



Activation: Handshake procedures 
(clause 8.2.3) 


Training 
(clause 8.2.4) 


Channel analysis and Exchange 
(clause 8.2.6) 



Figure 50: Overview of initialisation 
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Transitions between states or various operations are made following completion of the current state or the specific task 
rather than at fixed times. 

During initialisation (but not in the initial handshake phase) a special operation channel (SOC) is defined to exchange 
information. 



8.2.2 SOC protocol 



8.2.2.1 



Message Format 



The SOC uses an HDLC-like format with octet stuffing to delineate the messages as specified in 

ITU-T Recommendation G. 994.1 [6]. Reliable transmission is insured by using either an automatic repeat (AR) mode or 
a repeat request (RQ) mode. The maximum length of an SOC message shall be 1026 octets. This is the size of the 
payload before octet stuffing and addition of any flags. 

In the AR mode, the message encapsulated in the HDLC frame is automatically repeated. At least four idle flags (0x7E) 
are inserted in between frames. 

In the RQ mode, the messages encapsulated in HDLC frame are sent once. However, the VTU expecting the message 
can request that the remote side repeat it by sending a REPEAT_REQUEST message. This operation is necessary when 
the expected message contains bit errors detected by the CRC or when a timeout has expired. After two unsuccessful 
REPEAT_REQUEST messages, the initialisation is aborted. This means the initiating side will restart the handshake 
after a silent period. After a number of unsuccessful attempts, the modems shall stop all further attempts. The number of 
attempts made before the initialisation is aborted shall be chosen by the initiating modem. 

A SOC message contains an integer number of octets (8-bits per octet). The octets are sent least significant bit first. A 
message is subdivided into fields that can contain more than one octet. In the case of multi-octet fields the octet 
containing the most significant bits is sent first. For example, a field of 16 bits ml5, . . .,mO is segmented into a first octet 
BO = ml5,...,m8 and a second octet Bl = m7,...,m0. Some fields can be merged together to form a logical entity called 
a macro-field, such as "Mask Descriptor". 

The structure of an HDLC frame is illustrated in figure 5 1 . 



Meaning 


Value 

<r- 1 octet -> 


Flag 


0x7E 


Address Field 


Address 


Control Field 


Control 


Information Payload 


Payload Octets 


Check Sequence 


FCS 


Check Sequence 


FCS 


Flag 


0x7E 



Figure 51 : Structure of an l-IDLC frame 



8.2.2.2 



0/R IDLE 



When the VTU-O is in the idle state (i.e. it has no SOC message to send), it sends O-IDLE. The VTU-R sends R-IDLE 
when in the idle state. 

O-IDLE and R-IDLE correspond to the idle state of the HDLC protocol: 0x7E. This octet is transmitted repeatedly 
(i.e. there is no HDLC framing). 



8.2.2.3 



0/R REPEAT REQUEST 



This message requests the remote side to repeat the last unacknowledged message. Note that due to the structure of the 
initialisation sequence, all messages are acknowledged either by another message or by a symbol type transition. The 
information payload of the message is one octet: 0x55. In AR mode, REPEAT_REQUEST messages shall be ignored. 

When messages are segmented, the REPEAT_REQUEST messages shall be able to ask for the retransmission of a 
particular segment of a message. 
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8.2.2.4 



Message codes 



The information payload of every SOC message starts with a field (of 1 octet) containing a unique code to identify the 
message and to allow fast and easy recognition of each SOC message. The codes of all the messages used during the 
initialisation sequence are shown in table 49 in hexadecimal notation. They are arranged and numbered in the order in 
which they appear. The messages originating at the VTU-O have the MSB set to zero while the messages originating at 
the VTU-R have the MSB set to one. Some single octet messages have special codes. 

Table 49: Message codes used by the SOC 



SOC Message 


Message code 


0/R-REPEAT REQUEST 


0x55 (see note) 


R-ACK 


0x00 (see note) 


R-NACK 


OxFF (see note) 


0/R-ACK-SEG 


OxOF (see note) 


0-SIGNATURE 


0x01 


0-UPDATEn 


0x02 


0-MSG1 


0x03 


0-MSG2 


0x04 


0-GONTRAGTn 


0x05 


O-B&G 


0x06 


R-MSG1 


0x81 


R-MSG2 


0x82 


R-G0NTRAGT1 


0x83 


R-MARGINn 


0x84 


R-B&G 


0x85 


NOTE: This is the entire payload of the message. 



8.2.2.5 



Message fields 



Typically, the information contained in an SOC message will be subdivided into a number of fields. It is possible in the 
future that additional fields may be defined. To ensure backward compatibility, new fields will be appended to the 
currently defined fields. The modem shall ignore any extra fields following the currently defined fields in a message. 



8.2.2.6 



Segmentation of messages 



Some messages could potentially be large and exceed the maximum allowed frame size of an HDLC frame 
(1 026 octets). Messages can therefore be segmented before transmission. In order to do this, all messages transmitted 
during initialisation shall contain a sequence number. The sequence number is stored in one octet. The zero value is 
reserved (see later). This means that sequence number 255 is followed by sequence number 1. 

The sequence number is transmitted in the Address Field of the HDLC frame (see figure 51). The sequence number is 
used to detect lost messages and to request the retransmission of a particular message. The sequence number is initially 
set to one and is incremented by one after the transmission of a message. The sequence number is not incremented in 
response to a REPEAT-REQUEST. The counting of messages starts when the transmission starts using RQ mode 
instead of automatic repeat mode. 

A segmentation index (1 octet) is included in the Control Field of the HDLC frame. The four MSB's of this field 
indicate the number of segments that make up the total message. The four LSB's indicate the index of the current 
segment. For instance a value 0x93 indicates the third segment of a total of nine. When the message is not segmented, 
the value of the field shall be Ox 11 . 

The REPEAT-REQUEST message will behave differently from the other messages. The meaning of the sequence 
number and the segmentation index is different in this case. 

The sequence number field of the REPEAT-REQUEST message shall contain the sequence number of the message to 
be retransmitted. The default value of zero indicates that the last unacknowledged message shall be resent. If this 
message contains several segments, only the last segment shall be retransmitted. 

Likewise, the segmentation field will contain the number of the segment that shall be retransmitted. The Information 
payload of the REPEAT-REQUEST message will still consist of one octet with a value 0x55. 
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During the initialisation procedure a transmitter shall not send a second message without receiving an acknowledgement 
of the first message. It shall always receive a message from the other side before transmitting again. Therefore, an 
acknowledgement shall be sent for all but the last segment. Typically, the last segment signals the end of the message 
and it will therefore be acknowledged by the reply to this message. The ACK-SEG-message (see table 49) shall be used 
to acknowledge the reception of the other segments. The ACK-SEG-message will have its own sequence number and 
segment index and does not refer to the segmented message that is being sent. 

Once acknowledged, messages (or segments) are not expected to be retransmitted again. 

Any REPEAT-REQUEST received with a sequence number ahead of the current sequence number shall be ignored. 

In AR mode, segmentation shall be done in the same way, but there will be no acknoledgements (ACK-SEG) between 
different segments of the same message. Segments shall be sent in order. 

8.2.3 Handshake procedure 

The handshake procedure is based on ITU-T Recommendation G. 994.1 [6] (G.hs). It uses the 4,3125 kHz signalling 
family and the duplex transmission mode. The initial handshake transmission shall use all carrier sets as defined in 
ITU-T Recommendation G. 994.1 [6] clause 6.1.1. Annex E contains provisional values that will be superseded by 
ITU-T Recommendation G. 994.1 [6]. All carrier frequencies within a carrier set and all carrier sets are simultaneously 
modulated with the same data bits using Differentially encoded binary Phase Shift Keying (DPSK), as defined in 
ITU-T Recommendation G. 994.1 [6]. During the handshake procedure, the following parameters shall be transmitted: 

• The size of IDFT/DFT (note that the size of the (I)FFT is twice the number of tones Nsc; 

• The initial length of the cyclic extension; 

• Flags indicating the use of the optional band, 25 kHz -138 kHz. 

The parameters above shall be encoded using the Standard information fields defined for VDSL. 

The handshake procedure is followed by a silent period after which the VTU-O enters the training state. 

The 4,3125 kHz signalling family as defined in ITU-T Recommendation G.994.1 [6] clause 6.1.1 shall be used. 

8.2.3.1 Message coding format 

The message information field consists of three components: an identification field, a standard information field, and an 
optional non-standard information field as shown in figure 52. The overall message composition is specific for each 
message type in the identification field. 



Identification (1) 
field 


Standard information (S) 
field 


Non-standard information 
(NS) field 



Figure 52: Information field structure 

8.2.3.1.1 Identification field (I) 

The identification field specifies the type of message and provides vendor identification and service or application 
related information. The identification field coding shall be as defined in ITU-T Recommendation G.994.1 [6]. The 
message type and its field format shall also be as defined in ITU-T Recommendation G.994.1 [6]. 
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8.2.3.1.2 



Standard information field (S) 



The NPar(l) and SPar(l) coding of the standard information field shall be as defined in 

ITU-T Recommendation G. 994.1 [6]. The coding of NPar(2), SPar(2) and Npar(3) is listed in tables 50 to 54 and are 

defined in clause 8.2.3.2. 



Bits 



Table 50: Standard information field - ETSI MCM VDSL NPar(2) coding 



NPar(2)s 

Upstream use of lower band 

Downstream use of lower band 

Reserved 

SIM 

ATM 

G.997.1 - Clear EOC 0AM 

No parameters in this octet 



8 


7 


6 


5 


4 


3 


2 


1 


X 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


X 





















Bits 



Table 51 : Standard information field - ETSI MCM VDSL SPar(2) coding 



SPar(2)s 

Sub-channel information (see note) 

Reserved 

Reserved 

IDFT/DFTsize 

Initial length of CE 

Reserved 

No parameters in this octet 



8 


7 


6 


5 


4 


3 


2 


1 


X 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


1 


X 


X 


X 


X 


X 


X 


X 





















NOTE: The use of this bit is for further study and shall be set to zero in CLR, CL, and MS messages. This bit 
specifies the supported bearer channels for VDSL upstream/downstream transmissions in the TPS-TC 
sub-layer. The bearer channels are for further study. 

Table 52: Standard information field - ETSI MCM VDSL NPar(3) coding for IDFT/DFT size 



NPar(3)s 

IDFT/DFT size (n x 256 points) 



Bits 

8 7 


6 


5 


4 


3 


2 


1 


X X 


ns 


n4 


ns 


n2 


ni 


no 



Table 53: Standard information field - ETSI MCM VDSL NPar(3) coding for CE length - Octet 1 



Bits 

8 7 



X X 



1 NPar(3)s - Octet 1 



ceg cea cey cee initial sample length of cyclic extension (high order bits) 



Table 54: Standard information field - ETSI MCM VDSL NPar(3) coding for CE length - Octet 2 



Bits 

8 7 



1 NPar(3)s - Octet 2 



005 004 003 002 cei coo initial sample length of cyclic extension (low order bits) 
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8.2.3.2 



Handshake procedures and Message field settings 



8.2.3.2.1 



Handshake - VTU-0 



The detailed procedures for handshake at the VTU-O are defined in ITU-T Recommendation G.994.1 [6]. A VTU-O, 
after power-up, loss of signal or recovery from errors during the initialisation procedure, shall enter the initial 
ITU-T Recommendation G.994.1 [6] state C-SILENTl. The VTU-O may transition to the Initialisation Reset Procedure 
under instruction from the network. From either state, operation shall proceed according to the procedures defined in 
ITU-T Recommendation G.994.1 [6]. 

If ITU-T Recommendation G.994. 1 [6] procedures select VDSL as the mode of operation, the VTU-O shall transition to 
state O-QUIET at the conclusion of ITU-T Recommendation G.994. 1 [6] operation. 



8.2.3.2.1.1 



CL messages 



A VTU-O wishing to indicate VDSL capabilities during an ITU-T Recommendation G.994.1 [6] CL message shall do 
so by setting to one the Level 1 SPar(l) ETSI MCM VDSL bit as defined in table C.5. The NPar(2) and SPar(2) fields 
corresponding to the VDSL Level 1 bit are defined in table 50 and table 51, respectively. For each Level 2 SPar(2) bit 
that is set to one, a corresponding NPar(3) field shall also be present. These NPar(3) fields are defined in tables 52 
through 54. The Level 2 bits in a CL message are defined in tables 55 and 56. 

Table 55: VTU-O CL message NPar(2) bit definitions 



NPar(2) bit 


Definition 


Upstream use of lower band 


If set to one signifies that the VTU-O is capable of using the band 
between 25 kHz and 1 38 kHz and that the band can be used for the 
upstream transmission. 


Downstream use of lower band 


If set to one signifies that the VTU-O is capable of using the band 
between 25 kHz and 1 38 kHz and that the band can be used for the 
downstream transmission. 


STM 


If set to one signifies that the VTU-O can be configured for STIVI bit 
synchronous transport. 


ATM 


If set to one signifies that the VTU-O can be configured for ATIVI cell 
transport. 


EOC-Clear 


If set to one signifies that the VTU-O supports transmission and 
reception of ITU-T Recommendation G. 997.1 [8] OAIVI frames. 



Table 56: VTU-O CL message SPar(2) bit definitions 



SPar(2) bit 


Definition 


IDFT/DFTsize 


Always set to one in a CL message. It indicates the maximum 
IDFT/DFT size that the VTU-O can support. The value shall be present 
in the corresponding NPar{3) field. 


Initial length of CE 


If set to zero, it indicates that the VTU-O can only support the 
mandatory CE length of 40x2" with the number of tones equal to 
256x2". If set to one, it indicates the initial sample length of the cyclic 
extension that the VTU-O can support. It also signifies that the VTU-O 
can support CE lengths other than the mandatory length. The value 
shall be present in the corresponding NPar(3) field. If one of the 
modems only supports the mandatory value, then this value shall be 
used. 



At least one of the STM and ATM bits shall be set to one in a CL message. 
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8.2.3.2.1.2 



MS messages 



A VTU-O selecting VDSL operation in an ITU-T Recommendation G.994.1 [6] MS message shall do so by setting to 
one the Level 1 SPar(l) ETSI MCM VDSL bit as defined in table C.5. The NPar(2) and SPar(2) fields corresponding to 
this bit are defined in tables 50 and 51 respectively. For each Level 2 SPar(2) bit set to one, a corresponding NPar(3) 
field shall also be present as defined in tables 52 through 54. The Level 2 bits in an MS message fi^om the VTU-O are 
defined in tables 57 and 58. 

Table 57: VTU-O MS message NPar(2) bit definitions 



NPar(2) bit 


Definition 


Upstream use of lower band 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the band between 
25 l<Hz and 138 kHz shall be used for the upstream transmission. 


Downstream use of lower band 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the band between 
25 l<Hz and 138 kHz shall be used for the downstream transmission. 


STM 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the VTU-O and 
VTU-R shall be configured for STM bit synchronous transport. 


ATM 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the VTU-O and 
VTU-R shall be configured for ATM cell transport. 


EOC-Clear 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the VTU-O and 
VTU-R may transmit and receive ITU-T Recommendation G.997.1 [8] 
0AM frames. 



Table 58: VTU-O MS message SPar(2) bit definitions 



SPar(2) bit 


Definition 


IDFT/DFTsize 


Always set to one in an MS message. It indicates the maximum 
IDFT/DFT size that the VTU-O and VTU-R can support. The value 
shall be present in the corresponding NPar(3) field. 


Initial length of CE 


If set to zero, it indicates that the VTU-O can only support the 
mandatory CE length of 40x2" with the number of tones equal to 
256x2". If set to one, it indicates the initial sample length of the cyclic 
extension that the VTU-O can support. It also signifies that the VTU-O 
can support CE lengths other than the mandatory length. The value 
shall be present in the corresponding NPar(3) field. If one of the 
modems only supports the mandatory value, then this value shall be 
used. 



If "Upstream use of lower band" and "Downstream use of lower band" are both set to one in the CL and CLR messages, 
only one of the bits shall be set to one in an MS message sent from the VTU-O and the VTU-O shall choose the 
transmission direction of the lower band. If the VTU-O and VTU-R have no common usage of the lower band, both bits 
shall be set to zero in an MS message sent from the VTU-O. 

Only one of the STM and ATM bits shall be set to one in an MS message sent from the VTU-O. If both bits are set in 
the CL and CLR messages, the VTU-O shall choose the transport mode. 



8.2.3.2.2 



Handshake - VTU-R 



The detailed procedures for handshake at the VTU-R are defined in ITU-T Recommendation G.994.1 [6]. A VTU-R, 
after power-up, loss of signal or recovery from errors during the initialisation procedure, shall enter the initial 
ITU-T Recommendation G.994.1 [6] state R-SILENTO. Upon command from the host controller, the VTU-R shall 
initiate handshaking by invoking the Initialisation Reset Procedure. Operation shall then proceed according to the 
procedures defined in ITU-T Recommendation G.994.1 [6]. 

If ITU-T Recommendation G.994.1 [6] procedures select VDSL as the mode of operation, the VTU-R shall transition to 
state R-QUIET at the conclusion of ITU-T Recommendation G.994.1 [6] operation. 
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8.2.3.2.2.1 



CLR messages 



A VTU-R wishing to indicate VDSL capabilities during in an ITU-T Recommendation G. 994.1 [6] CLR message shall 
do so by setting to one the Level 1 SPar(l) ETSI MCM VDSL bit as defined in table C.5. The NPar(2) and SPar(2) 
fields corresponding to the VDSL Level 1 bit are defined in tables 50 and 5 1 respectively. For each Level 2 SPar(2) bit 
set to one a corresponding NPar(3) field shall also be present. These NPar(3) fields are defined in tables 52 through 54. 
The Level 2 bits in a CLR message are defined in tables 59 and 60. 

Table 59: VTU-R CLR message NPar(2) bit definitions 



NPar(2) bit 


Definition 


Upstream use of lower band 


If set to one signifies tliat the VTU-R is capable of using the band 
between 25 kHz and 1 38 kHz and that the band can be used for the 
upstream transmission. 


Downstream use of lower band 


If set to one signifies that the VTU-R is capable of using the band 
between 25 kHz and 1 38 kHz and that the band can be used for the 
downstream transmission. 


STM 


If set to one signifies that the VTU-R can be configured for STM bit 
synchronous transport. 


ATM 


If set to one signifies that the VTU-R can be configured for ATM cell 
transport. 


EOC-Clear 


If set to one signifies that the VTU-R supports transmission and 
reception of ITU-T Recommendation G.997.1 [8] 0AM frames. 



Table 60: VTU-R CLR message SPar(2) bit definitions 



SPar(2) bit 


Definition 


IDFT/DFTsize 


Always set to one in a CLR message. It indicates the maximum 
IDFT/DFT size that VTU-R can support. The value shall be present in 
the corresponding NPar(3) field. 


Initial length of CE 


If set to zero, it indicates that the VTU-0 can only support the 
mandatory CE length of 40x2" with the number of tones equal to 
256x2". If set to one, it indicates the initial sample length of the cyclic 
extension that the VTU-0 can support. It also signifies that the VTU-0 
can support CE lengths other than the mandatory length. The value 
shall be present in the corresponding NPar(3) field. If one of the 
modems only supports the mandatory value, then this value shall be 
used. 



At least one of the STM and ATM bits shall be set to one in a CLR message. 



£75/ 



119 



ETSI TS 101 270-2 V1.2.1 (2003-07) 



8.2.3.2.2.2 



MS messages 



A VTU-R selecting VDSL operation in an ITU-T Recommendation G. 994.1 [6] MS message shall do so by setting to 
one the Level 1 SPar(l) ETSI MCM VDSL bit as defined in table C.5. The NPar(2) and SPar(2) fields corresponding to 
this bit are defined in tables 50 and 51 respectively. For each Level 2 SPar(2) bit set to one a corresponding NPar(3) 
field shall also be present, as defined in tables 52 through 54. The Level 2 bits in an MS message from the VTU-R are 
defined in tables 61 and 62. 

Table 61 : VTU-R MS message NPar(2) bit definitions 



NPar(2) bit 


Definition 


Upstream use of lower band 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the band between 
25 l<Hz and 138 kHz shall be used for the upstream transmission. 


Downstream use of lower band 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the band between 
25 l<Hz and 138 kHz shall be used for the downstream transmission. 


STM 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the VTU-0 and the 
VTU-R shall be configured for STM bit synchronous transport. 


ATM 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the VTU-0 and the 
VTU-R shall be configured for ATM cell transport. 


EOC-Clear 


If this bit was set to one in the last CL message and the last CLR 
message then it shall be set to one. It signifies that the VTU-0 and the 
VTU-R may transmit and receive ITU-T Recommendation G.997.1 [8] 
0AM frames. 



Table 62: VTU-R MS message SPar(2) bit definitions 



SPar(2) bit 


Definition 


IDFT/DFTsize 


Always set to one in an MS message. It indicates the maximum 
IDFT/DFT size that the VTU-0 and the VTU-R can support. The value 
shall be present in the corresponding NPar(3) field. 


Initial length of CE 


If set to zero, it indicates that the VTU-0 can only support the 
mandatory CE length of 40x2" with the number of tones equal to 
256x2". If set to one, it indicates the initial sample length of the cyclic 
extension that the VTU-0 can support. It also signifies that the VTU-0 
can support CE lengths other than the mandatory length. The value 
shall be present in the corresponding NPar(3) field. If one of the 
modems only supports the mandatory value, then this value shall be 
used. 



If "Upstream use of lower band" and "Downstream use of lower band" are both set to one in the CL and CLR messages, 
only one of the bits shall be set to one in an MS message sent from the VTU-R and the VTU-R shall choose the 
transmission direction of the lower band. If the VTU-O and VTU-R have no common usage of the lower band, both bits 
shall be set to zero in an MS message sent from the VTU-R. 

Only one of the STM and ATM bits shall be set to one in an MS message sent from the VTU-R. If both bits are set in 
the CL and CLR messages, the VTU-R shall choose the transport mode. 
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8.2.4 Training state 

Figure 53 gives an overview of the sequence of SOC messages and symbol types that are transmitted by the VTU-O and 
VTU-R during the training phase. 



SOC Messages 



O-IDLE 

(optional) 



0-SIGNATURE 
(auto-repeated) 



O-UPDATEl 



0-UPDATEn 



See channel 
analysis and 



R-MSGl 

(auto-repeated) 



R-ACK/R-NACK 



R-ACK/R-NACK 



See channel 

analysis and 

exchange 



Symbol Types 



O-P-TRAINING 



O-P-SYNCHRO 



O-P-TRAlNlNG 



0-P-MEDLEY 



R-P-TRAINING 



R-P-TRAINlNGn 



R-P-TRAlNINGn+1 



R-P-SYNCHRO 



R-P-TRAININGn-l-1 



R-P-MEDLEY 



.Change of CE 



Figure 53: Timeline of training phase 



8.2.4.1 



Sequence of messages and symbols during training. 



The sequence of messages is illustrated in figure 53. 

The VTU-O initiates the start of the training phase by transmitting O-SIGNATURE using the symbol type 
O-P-TRAINING. The message O-SIGNATURE is sent over the SOC using AR mode. During this first phase, the 
modems synchronise. 

Once the VTU-R is synchronised and has successfully decoded the O-SIGNATURE message, it transmits the symbol 
R-P-TRAINING. The SOC will transmit the message R-MSGl. The VTU-O keeps transmitting the O-P-TRAINING 
symbol and the O-SIGNATURE message. Optionally the VTU-O can transmit the O-IDLE message (since 
O-SIGNATURE has already been decoded at the VTU-R). During this phase the VTU-O can optimise timing advance 
and measure the received PSD at the VTU-O side. Once this is completed the VTU-O can initiate the next phase by 
transmitting the SOC message O-UPDATEl . 

In this last phase, the transmit PSD of the VTU-R is tuned in an iterative procedure. The VTU-O sends a change request 
by sending the O-UPDATEn message. The VTU-R responds to each message by sending an R-ACKn or R-NACKn 
reply. Five symbols after the R-ACK message is sent, the VTU-R transmits the symbol R-P-TRAININGn-nl. 

If R-NACK is sent the VTU-O continues the iterative process by sending O-UPDATEn-nl or ends the process by 
sending O-MSGl. 

This last phase shall be terminated by the VTU-O by sending the SOC message O-MSGl. Upon detection of O-MSGl, 
the VTU-R shall transmit the symbol R-P-SYNCHROl. The VTU-O shall reply with O-P-SYNCHROl. Both sides 
shall simultaneously update the CE, reset the quadrant scramblers and enter the next state (channel analysis and 
exchange) Z)r seconds after the last symbol of O-P-SYNCHRO 1 has been sent. Z)r shall correspond to 15 DMT 
symbols (using the initial value for the cyclic extension). 
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8.2.4.2 Messages and symbols sent by the VTU-0 

8.2.4.2.1 SOC messages 

During the training phase, the VTU-O will send the SOC messages O-SIGNATURE, O-UPDATEn and O-MSGl as 
well as the idle message O-IDLE. 

Clause 8.2.4.2.2 describes how the messages are modulated onto the transmit symbol. 

8.2.4.2.1.1 O-SIGNATURE 

This message contains nine fields: 

• message descriptor; 

• the bands used in the downstream direction; 

• the bands used in the upstream direction; 

• the bands notched for RFI ingress/egress reduction; 

• transmit PSD in the downstream direction; 

• whether the VTU-O shall specify a maximum allowed receive PSD or a maximum allowed transmit PSD; 

• the PSD mask in the upstream direction; 

• the reference PSD or maximum allowed transmit PSD in the upstream direction; 

• the overall length of the window at the transmitter (P). 
O-SIGNATURE is repeated automatically using the AR mode. 

Table 63: Description of message O-SIGNATURE 



Field content 


Field or lUlacro-field type 


Message descriptor 


IVIessage code (1 octet) 


Band used in downstream 


Band descriptor 


Band used in upstream 


Band descriptor 


Bands notched for RFI reduction 


Band descriptor 


Transmit PSD in downstream 


PSD descriptor 


Receive or transmit PSD mask selector 


1 octet 


PSD mask in upstream 


PSD descriptor 


IVIaximum allowed receive PSD in upstream direction 


PSD descriptor 


Length of the window at the transmitter 


1 octet 



Fields two, three and four contain a "band descriptor". The first octet of these fields contains the number of bands being 
described. After the first octet, groups of 3 consecutive octets describe each band. The first 12 bits (0-11) contain the 
index of the tone that resides at the lower edge of the band. The last 12 bits (12-23) contain the index of the tone at the 
upper edge of the band. The starting and ending tones are included in the band. For example, a field value 0x400200 
means that all tones from 0x200 = 512 to 0x400 = 1 024 are used, including tones 512 and 1 024. 

Table 64: Band descriptor 



Octet 


Content of field 


1 


Number of bands to be described 


2 to 4 


Bits to 1 1 : Start tone index of band 1 
Bits 12 to 23: Ending tone index of band 1 


5 to 7 (if applicable) 


Bits to 1 1 : Start tone index of band 2 
Bits 12 to 23: Ending tone index of band 2 


etc. 


etc. 
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Fields five, seven and eight contain a "PSD descriptor". The first octet of this field contains the number of tones being 

specified. After the first octet, groups of 3 consecutive octets describe the PSD. The first 12 bits (0-11) contain the 

index of the tone being described. The last 12 bits (12-23) contain the PSD level. The PSD level is an integer multiple 

of 0,5dB with an offset of -140dBm/Hz. For example a field value of 0x0A0400 means a PSD of 

OxOAO X 0,5 - 40 = -60 dBm/Hz on tone index 0x400 = 1 024. The PSD level of intermediate unspecified tones is 

obtained using a linear interpolation between the given PSD points (in dBm/Hz) with the frequency axis on a linear 

scale. 

The sixth field of O-SIGNATURE is a flag indicating whether the transmit PSD at the VTU-R shall be calculated from 
the maximum receive PSD (field eight) or not. If this field has the value OxFF, the upstream transmit PSD shall be 
calculated using the reference PSD given in field eight. If this field has a value of 0x00, the transmit PSD at the VTU-R 
shall be determined from the maximum upstream PSD only (field seven). 

Table 65: PSD descriptor 



Octet 


Content of field 


1 


Number of tones to be described 


2 to 4 


Bits to 11 : Index of first tone being described 

Bits 12 to 23: PSD level in steps of 0,5 dB with an offset of -140 dBm/Hz 


5 to 7 (if applicable) 


Bits to 1 1 : Index of second tone being described 

Bits 12 to 23: PSD level in steps of 0,5 dB with an offset of -140 dBm/Hz 


etc. 


etc. 


NOTE: The index n refers to frequencies used in the definition of the PSD mask. 



The last field in the O-SIGNATURE message contains the length of the transmit window, in samples at the sampling 
rate corresponding to the selected value of N. This sampling rate is given by 2Nsc4f(^-^- two times the Nyquist 
frequency of an A^^c-tone multi -carrier signal. 



8.2.4.2.1.2 



0-UPDATEn 



This message instructs the VTU-R to tune its transmit PSD to optimise the power back-off and allows the VTU-O to 
optimise the timing advance. O-UPDATEn is repeated only at the request of the VTU-R (see R-REPEAT_REQUEST 
in clause 8.2.2.3). This message contains a single "update descriptor" field. The first octet of the update descriptor 
contains the number of specified tones. Each specified tone is described using 3 octets and contains the gain level 
(12bits) at a given tone index (12 bits). The gain level is the amplification applied on one tone. It is specified in 2's 
complement format using 0,25 dB steps. For example a field value of 0x030400 means a PSD amplification of 0x030 X 
0,25 = 12 dB on the tone index 0x400 = 1 024. The gain on unspecified tones is derived by linear interpolation between 
tones specified using a dB gain scale and a linear frequency scale. 

The last field defines the timing advance correction in samples at the sampling rate corresponding to the negotiated 
value of N. The value is encoded in a 16 bit field using 2's complement format. 

Table 66: Description of message O-UPDATEn 



Field content 


Field or Macro-field type 


Message descriptor 


IVIessage code (1 octet) 


Gain update 


Update descriptor 


Timing advance correction 


2 octets 



Table 67: Update descriptor 



Octet 


Content of field 


1 


Number of tones to be described 


2 to 4 


Bits to 1 1 : Index of first tone being described 

Bits 12 to 23: Gain level adjustment in 2's complement in steps of 

0,25 dB 


5 to 7 (if applicable) 


Bits to 1 1 : Index of second tone being described 

Bits 12 to 23: Gain level adjustment in 2's complement in steps of 

0,25 dB 


etc. 


etc. 
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8.2.4.2.1.3 



0-MSG1 



This message contains the final length of the CE expressed in samples at the sampling frequency corresponding to the 
negotiated value of N. The message is described in table 68. The O-MSGl message is sent once but can be repeated if 
the VTU-R sends a repeat request. 

Table 68: Description of message O-IVISGI 



Field content 


Field or Macro-field type 


Message descriptor 


IVIessage code (1 octet) 


Final length of CE 


2 octets 



The final CE length shall be applied from the beginning of the channel analysis state. 



8.2.4.2.2 



Symbol types transmitted by the VTU-0 



During the entire training phase the VTU-O modem shall transmit the O-P-TRAINING symbol. To signal the end of the 
training phase, O-P-SYNCHROl shall be transmitted. 



8.2.4.2.2.1 



O-P-TRAINING 



O-P-TRAINING is a wideband signal that allows the VTU-R to synchronise and to measure the attenuation over the 
channel. It uses all of the allowed downstream tones (determined by management parameters) modulated in 4QAM. 
The symbol length is N H- CE samples. N and CE are negotiated during the initial ITU-T Recommendation G.994.1 [6] 
phase. Windowing is applied at the transmitter, with the overall window length P set by OAM. The transmitter PSD is 
defined by the network management. O-P-TRAINING carries one octet of information per DMT symbol. The 
information mapping is summarised in table 69, where the constellation labels correspond to the points in figure 7. 

Table 69: O-P-TRAINING bit mapping 



Tone index 


Constellation point (see note) 


Even 


00 


1, 11,21, ... 


see message bits and 1 


3, 13,23, ... 


see message bits 2 and 3 


5, 15,25,... 


see message bits 4 and 5 


7, 17,27, .... 


see message bits 6 and 7 


9, 19,29, ... 


00 



NOTE 1: If the two SOC message bits / and i+1 are denoted as Si and Si+i respectively, the constellation point is 

(Si, Si+i). 

The selected constellation points are pseudo-randomly rotated by 0, 7t/2, 7t, 37t/2 depending on a 2-bit pseudo-random 
number. The DC component is not rotated. The rotation is equivalent to the following transformation of the (X, Y) 
co-ordinates: 

Table 70: Pseudo-random transformation 



d2ii, d2n+1 


Angle of rotation 


Final co-ordinates 


00 





(X,Y) 


1 


nl2 


(-Y,X) 


1 1 


% 


(-X, -Y) 


1 


371/2 


(Y, -X) 



NOTE 2: (X,Y) is the original constellation point. 
The 2-bit sequence is the output of a pseudo-random bit generator defined by the following equation: 
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Two bits of the bit generator are mapped onto each tone including those at DC, however the bits for DC are overwritten 
by zeros. The bit generator is illustrated in figure 54. 

^ 











d„-i 


— ► 


d„.2 


' 









d„-9 



d„-n -' 



dn 



Figure 54: Pseudo-random bit generator 

For a VDSL system that uses A^ tones, 2N bits shall be generated by the scrambler every DMT symbol (do di d2 . . . d2N-2 
dzN-i)- These 2Nhits are generated in both transmission directions. The first two bit (do di) correspond to tone 0, the 
next two bits (d2 ds) to tone 1 etc. In general, bits (d2j d2j+i) correspond to tone j. Although not all tones are used for 
transmission all 2N bits shall be generated. 

Initially, all the registers are set to one. During the training phase the scrambler is reset at the start of every symbol 
(meaning that all registers are reset to one) and therefore the same 2N bits will be used every symbol. This means that 
each tone always has the same two bits assigned to it for successive DMT symbols. 

In the channel analysis state the scrambler will not be reset but keeps running from one symbol to the next. The 
sequence shall be random in time for one single tone. There shall be no correlation between the two bits that are 
mapped on tone j during symbol m and the two bits that are mapped on the same tone during symbol m+1. In order to 
guarantee this for all allowed values of A^, a number of output bits from the quadrant scrambler will be skipped when 
going from symbol m to symbol m+1. The number of bits skipped shall be four. 



8.2.4.2.2.2 



0-P-SYNCHR01 



O-P-SYNCHROl is a wideband signal that allows the VTU-O and the VTU-R to simultaneously step into the Channel 
Analysis & Exchange State. It shall use all of the allowed downstream tones modulated using 4QAM. The symbol 
length is N+CE samples, where the values of N and CE are set to the values specified during the initial handshake. 

Windowing shall be applied at the transmitter and the overall window length P is set to the value specified in 
O-SIGNATURE (clause 8.2.4.2.1.1). The PSD mask is defined by network management. The overall duration of 
O-P-SYNCHROl is 15 DMT symbols. The value 1 1 shall be mapped on all the allowed downstream tones for the first 
five and the last five DMT symbols. The value 00 shall be mapped on the allowed downstream tones for the five 
remaining DMT symbols. The selected constellation points shall be pseudo-randomly rotated by 0, 71/2, 71 or 371/2 
depending on the 2-bit random number provided by the pseudo-random bit generator defined in clause 8.2.4.2.2.1. The 
scrambler is reset every symbol. 



8.2.4.3 



Messages and symbols sent by the VTU-R 



8.2.4.3.1 



SOC messages 



During the training phase the VTU-R sends the SOC messages R-MSGl, R-ACKn and R-NACKn as well as the idle 
message R-IDLE. 

Clause 8.2.4.3.2 describes how the messages are modulated onto the transmit symbol. 



8.2.4.3.1.1 



R-MSGl 



This message contains the description of the transmit PSD of the VTU-R. This PSD is encoded in one macro-field "PSD 
Descriptor" as described in clause 8.2.4.2.1.1. The PSD level on unspecified tones is derived using a linear interpolation 
between the PSD in dBm/Hz of the specified tones, using a linear frequency axis. 

The method used to provide an initial estimate for the transmit PSD depends on the value of the selector flag octet in 
O-SIGNATURE. If the flag indicates that the modem shall obey a reference PSD mask at the VTU-O, it is computed by 
dividing the maximum allowed receive PSD by the estimate of the upstream channel insertion loss. Otherwise the 
transmit PSD is set to the upstream PSD mask that is transferred from the VTU-O to the VTU-R in the O-SIGNATURE 

message. 
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R-MSGl also indicates whether the optional echo canceller state shall be entered or bypassed. R-MSGl is repeated 
automatically until the VTU-R detects O-UPDATE. 

Table 71 : Description of R-IVISGI 



Field content 


Field or Macro-field type 


Message descriptor 


IVIessage code (1 octet) 


Transmit PSD in upstream 


PSD descriptor 


Echo canceller training flag 


0x00: no echo canceller training 
OxFF: echo canceller training required 



8.2.4.3.1.2 



R-ACKn 



This message is an acknowledgement of the O-UPDATEn message. It is sent only once unless the VTU-O requests a 
re-transmission. The message contains the octet 0x00. Five symbols after sending this message the VTU-R changes its 
symbol type from R-P-TRAININGn to R-P-TRAININGn-n 1 . On reception of this message the VTU-O could decide to 
ask for a new update by sending O-UPDATEn-nl or to end the iterative VTU-R PSD optimisation by sending O-MSGl. 

If the VTU-R receives a REPEAT_REQUEST message on this message, it takes the following actions to repeat the 

message: 

• Return to the symbol type R-P-TRAININGn; 

• Send back R-ACKn; 

• Return to the symbol type R-P-TRAININGn-n 1 . 



8.2.4.3.1.3 



R-NACKn 



This message is sent when the VTU-R is unable to apply the update encoded in O-UPDATEn. It is sent only once 
unless the VTU-O requests a re -transmission. The message contains one octet OxFF. Upon reception of this message the 
VTU-O can decide to continue the initialisation by sending either O-UPDATEn or O-MSGl or to abort the 
initialisation. 



8.2.4.3.2 



Symbol types transmitted by the VTU-R 



During the training phase the VTU-R shall transmit various R-P-TRAININGn symbols. The transition from training to 
channel analysis and exchange is triggered by the transmission of R-P-SYNCHROl. 



8.2.4.3.2.1 



R-P-TRAININGn 



R-P-TRAININGn is a wideband signal that allows the VTU-O to optimise the VTU-R timing advance (TA) and the 
VTU-R transmitted PSD mask in order to be compliant with the power back-off requirement. R-P-TRAINING uses all 
of the upstream tones modulated in 4QAM. The symbol length is N H- CE samples. N and CE are specified during the 
initial handshake phase. Windowing is applied at the transmitter, with the window length P as specified in 
O-SIGNATURE. The PSD mask is chosen to be compliant with the power -back-off requirement defined in 
O-SIGNATURE (clause 8.2.4.2.1.1). Afterward the VTU-O instructs the VTU-R to tune the upstream transmit PSD 
based on information in O-UPDATEn (clause 8.2.4.2.1.2). At the first iteration (R-P-TRAINING 1) the timing advance 
is set to a value corresponding to the maximum loop length (1,5 km or 7,5 )a.s). Afterwards the timing advance is 
updated as per the instructions transmitted by the VTU-O by means of O-UPDATEn (clause 8.2.4.2.1.2). 
R-P-TRAINING carries one octet of information per DMT symbol. The information mapping is summarised in 
table 72. 
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Table 72: R-P-TRAINING bit mapping 



Tone index 


Constellation point 


Even 


00 


1, 11,21, ..., 10n+1, ... 


SOC message bits and 1 


3, 13,23, ..., 10n+3, ... 


SOC message bits 2 and 3 


5, 15,25, ..., 10n+5, ... 


SOC message bits 4 and 5 


7, 17,27, ..., 10n+7, ... 


SOC message bits 6 and 7 


9, 19,29, ..., 10n+9, ... 


00 



The selected constellation points are pseudo-randomly rotated by 0, 7t/2, n, 3n/2 depending on a 2-bit pseudo-random 
sequence provided by the pseudo-random generator described in clause 8.2.4.2.2.1. The DC component is not rotated. 
The generator is reset at the start of every symbol. 



8.2.4.3.2.2 



R-P-SYNCHR01 



R-P-SYNCHROl is a wideband signal that allows the VTU-O and the VTU-R to simultaneously step into the Channel 
analysis & Exchange State. It uses all of the allowed upstream tones modulated in 4QAM. The symbol length is N H- CE 
samples. N and CE are specified during the initial ITU-T Recommendation G. 994.1 [6] phase. Windowing is applied at 
the transmitter and the overall window length P is set to the value specified in O-SIGNATURE. The transmitter PSD 
mask meets the power back-off requirements. The timing advance is applied and corresponds to the loop length. The 
duration of R-P-SYNCHROl is 15 DMT symbols. A fixed phase value of 11 is mapped on all the upstream tones for 
the first five and last five symbols. A fixed phase value of 00 is mapped on all the upstream tones for the middle five 
symbols. The selected constellation points are pseudo-randomly rotated by 0, k/2, k, 3k/2 depending on the 2-bit 
random number generated by a pseudo-random bit generator defined in clause 8.2.4.2.2.1. The generator is reset at the 
start of every symbol. 

8.2.5 Echo canceller training state (optional) 

The echo canceller state is optional in the sense that it will be skipped when modems do not need to train an echo 
canceller. Any modem that requires this state shall be able to demand that it is included in the initialisation sequence. 

Some modems may use an (analog) echo canceller that will have to be trained at some point during the initialisation 
sequence. During the training of an echo canceller, the other side should be completely quiet. 

Such a silent period exists for the VTU-O at the beginning of the training state. Here, the VTU-R will be quiet until it 
has decoded O-SIGNATURE correctly. This period could be used by the VTU-O to train its echo canceller. It could 
even make the available period longer by delaying the transmission of O-SIGNATURE and sending IDLE messages 
instead. 

The VTU-R does not have a convenient echo canceller training state however. Therefore, the modems can follow two 
different paths after the PSD training. It is signalled in R-MSGl whether an echo canceller training state is required for 
the VTU-R. If so, both modems will go to the echo canceller training state at the end of the PSD training state. 

In the echo canceller training state, the VTU-O will go completely silent after transmission of O-MSGl and perform no 
operations, other than listening to the signal on the line. After reception of O-MSGl, the VTU-R will keep transmitting 
the same signal as during the last phase of the training state. 

In this state, the VTU-R can train its echo canceller with a proprietary algorithm. After completion of this task, the 
VTU-R will go completely silent. This transition (no power on the line) should be detected by the VTU-O, which will 
react by returning to the beginning of the training state (synchronisation). Note that the situation is now identical to that 
at the beginning of initialisation: the VTU-R is quiet and the VTU-O starts the communication. 

After performing an echo canceller training, R-MSGl should be changed such that at the second pass through the PSD 
training state, the sequence will continue with the channel analysis state and not perform another echo canceller 
trairring. 

At the second pass, the VTU-R already knows its correct transmit PSD, so the training phase will be automatically 
shortened. There is no need to explicitly bypass any stages. 
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Figure 55: Position of (optional) echo canceller training state in the initialisation procedure 

8.2.6 Channel analysis and exchange 

Figure 56 gives an overview of the sequence of SOC messages and symbol types during the channel analysis and 
exchange phase. 



SOC Messages 



O-CONTRACTn 



R_CONTRACTl 



R-MARGINl 



SOC inactive 



Symbol Types 



O-P-MEDLEY 



O-P-SYNCHRO 



R-P-MEDLEY 



R-P-SYNCHRO 



8.2.6.1 



Figure 56: Timeline of the channel analysis and exchange phase 

Sequence of messages and symbols during channel analysis and exchange 



The sequence of SOC messages and symbols is depicted in figure 56. Upon entering the channel analysis and exchange 
state the VTU-R transmits symbol type R-P-MEDLEY, while the VTU-O transmits O-P-MEDLEY. The VTU-R sends 
the R-MSG2 message to transfer information about its bit allocation capabilities and other features. After receiving this 
message the VTU-O will do the same by sending the 0-MSG2 message. 

After receiving 0-MSG2 the VTU-R sends the R-CONTRACTl message. The VTU-O and VTU-R then enter an 
iterative procedure to agree on a contract for the transmission. At the n-th iteration, the VTU-O will send 
O-CONTRACTn. The VTU-R will reply with R-MARGINn. 
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To end the contract negotiations, the VTU-O transmits the message O-B&G. After receiving this message, the VTU-R 
sends the message R-B&G. After receiving R-B&G, the VTU-O initiates the transition to showtime by sending the 
symbol 0-P-SYNCHR02, which allows a simultaneous transition at both sides in the downstream direction. The 
VTU-R will reply by sending the message R-P-SYNCHR02, which allows a simultaneous transition in the upstream 
direction. 



8.2.6.2 



Messages and symbols send by the VTU-O 



8.2.6.2.1 



SOC messages 



During the channel analysis and exchange phase the VTU-O will send the SOC messages O-MSGl, O-CONTRACTn 
and O-B&G as well as the idle message O-IDLE. 

Clause 8.2.6.2.2 describes how the messages are modulated onto the transmit symbols. 

The sequence in which the messages are sent is illustrated in figure 56. 

During this state, all messages are sent in RQ-mode (clause 8.2.2.1). 

8.2.6.2.1.1 0-MSG2 

This message contains information about the capabilities of the VTU-O to negotiate a contract. 

Table 73: Description of 0-l\/ISG2 



Field content 


Field or macro-field type 


Remark 


Message descriptor 


1 octet 


See table 49 


Minimum Margin 


1 octet 


In units of 0,5 dB 


Maximum constellation size in 
downstream 


1 octet 


Maximum number of bits per tone 


RS settings supported by VTU-O 


1 octet 


0x00: only mandatory settings 
OxFF: all settings (see note 1) 


Interleaver setting supported by 
VTU-O 


1 octet 


0x00: only mandatory settings 
OxFF: all settings 
OxNN: NN = number of settings 
(0x00 < NN < OxFF) 


Detained interleaver setting 
description 


octets if NN = 0x00 

octets if NN = OxFF 

NN X 4 octets otherwise 


Interleaver description see table 
74 


Maximum power in downstream 


1 octet 


In units of 0,25 dBm 


Required interleaver delay 


1 octet 


In units of 0,5 ms (see note 2) 


Maximum number of EOC octets 
per frame in downstream 


1 octet 


Number of EOC octets per frame 


Maximum number of VOC octets 
per frame in downstream 


1 octet 


Number of VOC octets per frame 


Support of express swapping 


1 octet 


0x00: Not supported 
OxFF: Supported 


J max 


1 octet 


Maximum value of jmax supported 
by the VTU-O (see note 3) 


NOTE 1 : All settings means the values (for the redundancy) that are specified in clause 6.4.2. 
NOTE 2: This field can be set to zero in order to emulate the fast channel. This field is used for the 

creation of R-C0NTRACT1 even if dual latency is used later. 
NOTE 3: Specification of jmax = k means that all values from to k are supported. 



The structure of the interleaver description is shown in table 74. It lists the parameters of the interleaver. A number of 
these macrofields (depending on the value of NN) can be included in 0/R-MSG2. 
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Table 74: Interleaver description 



Field 


Field or macrofield type 


; 


1 octet 


Q 


1 octet 


Mmin 


1 octet 


Mmax 


1 octet 


NOTE: The four fields are repeated for each interleaver setting. 



8.2.6.2.1.2 



0-CONTRACTn 



This message consists of a proposal for an upstream and downstream contract and the EOC and VOC capacity, based 
on the EOC and VOC capabiHties of both modems (exchanged during O-MSGl and R-MSGl). The downstream 
contract is based on the information carried by R-CONTRACTl. Ideally the downstream contract is the same as the one 
proposed in R-CONTRACTl . 

Table 75 describes O-CONTRACTn. Both upstream and downstream values are encoded in a macro-field called 
"Contract Descriptor". The contract descriptor is defined in table 73. This macro-field contains all the necessary data for 
the setting of the framing. 

Table 75: Description of 0-CONTRACTn 



Field 


Field or macro-field type 


IVIessage descriptor 


IVIessage code (1 octet) 


Downstream contract 


Contract Descriptor 


Upstream contract 


Contract Descriptor 


EOC capacity 


Number of EOC octets per frame (1 octet) 


VOC capacity 


Number of VOC octets per frame (1 octet) 



Table 76: Contract Descriptor 



Field 


Field or macro-field type 


Remark 


Rate in fast channel 


2 octets 


In multiple of 64 kbps 


RS setting in fast channel 


2 octets 


b15^b8: RS overhead 

b7 -^ bO: RS codeword length 


Rate in slow channel 


2 octets 


In multiple of 64 kbps 


RS setting in slow channel 


2 octets 


b15^b8: RS overhead 

b7 -^ bO: RS codeword length 


Interleaver setting 


2 octets 


blS^'bS: IVI (see note 1) 
b7 ^ bO: I 


NOTE: The value / must be a divider of the RS codeword length. 



8.2.6.2.1.3 



O-B&G 



O-B&G shall signal the end of the contract negotiation and shall be used to transmit to the VTU-R the bits and gains 
information for the upstream direction. 

The number of bits to be coded onto carrier / is denoted as bi. The gain scale factor that shall be applied to carrier / 
(relative to the gain used during the transmission of R-P-MEDLEY) is denoted as g. 

The bi and g; values are only defined for those tones that are used during the transmission of R-P-MEDLEY (i.e. the 
upstream tones indicated in O-SIGNATURE). Because no bits or energy will be transmitted at the other frequencies 
(at least in the opposite direction) the corresponding bj and gj values are all presumed to be set to zero and shall not be 
transmitted. 



The bj and gi values shall be transmitted in ascending order (i.e. from lowest to highest tone). In case all bi values above 
a certain tone are zero, the remaining zero values do not have to be transmitted. The VTU-R shall assume that any 
missing values after the last received value correspond to tones that carry no bits. 



Each bi shall be represented as an unsigned 4-bit integer with a value in the range of zero to Bn 
maximum number of bits that the modem is prepared to modulate onto any sub-carrier. 



u which is the 
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Each gi shall be represented as an unsigned 12-bit fixed-point quantity with the binary point assumed just to the right of 
the third most significant bit. For example a gj with binary representation (most significant bit listed first) 
001,0100000002 would instruct the modem to scale the constellation for carrier / by a gain of 1,25 so that the power in 
that carrier shall be 1,94 dB higher than it was during R-P-MEDLEY. 

The whole spectrum may be split up into groups of adjacent tones such that the number of bits allocated to the carriers 
of a group is constant. The number of carriers in each group need not be constant but cannot exceed 256 carriers. The 
scale factor for each carrier within a group is defined by a polynomial interpolation. Only the parameters of the 
polynomial shall be transmitted. This polynomial is specified by means of the values of (jmax+1) defined tones where 
jniax is the order of the polynomial. The (jmax+l) tones are chosen to be equidistant. In the case of a group of carries 
[Xn, Xn+i] where x,, and x^+i are the index of the lowest and highest tones respectively of the n-th group of carriers the 
Qmax+1) X„j positions are defined as: 



^nj =\ + 



jx{x„^i-x„) 



in 



for j=0...j; 



At the VTU-O the value of j^a^ is chosen based on the values supported by the VTU-R as specified in R-MSG2. 
An O-B&G message is defined as: 

Table 77: Description of O-B&G messages 



Field content 


Field or Macro-field type 


Message descriptor 


1 octet 


J max 


1 octet 


bi and gi information 


B&G descriptor 



Table 78: B&G descriptor jmax=0 



Octet 



Content of field 



2n + 1 



2n + 2 



Specification of tone n+1 for n : 
Bits - 3: number of bits bn 
Bits 4-15: scale gain gp. 



to N - 2 (see note) 



NOTE: If tone n is not used in the upstream direction the specification is not 
transmitted. 



Table 79: B&G descriptor jmax>0 and odd 



Octet 


Content of field 


1-2 


Nqr Number of group of tones 


3 + n X(1,5xjmax+ 3,5) 
3 + (n+1)x(1,5xjmax+3,5)- 1 


Specification of tone in group n + 1 for n = to Ngr- 1 

Bits - 3: number of bits 

Bits 4-15: number of carriers of group n 

Bits 16 + 121 ^27 + 12i: g^ for tone X^j j = Otojmax. 



Table 80: B&G descriptor jmax>0 and even 



Octet 


Content of field 


1-2 


Nqr Number of group of tones 


3 + nx(1,5xjrT,ax+3) 

3 + (n + 1)x(1,5xj™x+3)- 

1 


Specification of tone in group n + 1 for n = to Ngr - 1 

Bits - 3: number of bits 

Bits 4-11: number of carriers of group n 

Bits 12 + 121 ^23 + 121: g^ for tone X^j j = Otojmax. 
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8.2.6.2.2 



Symbol types transmitted by the VTU-0 



8.2.6.2.2.1 



0-P-MEDLEY 



O-P-MEDLEY is a wideband signal used for estimation at the VTU-R of the downstream SNR. O-P-MEDLEY uses all 
of the downstream tones modulated in 4QAM. The symbol length is N + CE samples. N shall be set to the value 
specified during the handshake procedure and CE shall be set to the value specified in O-MSGl (clause 8.2.4.2.1.3). 
The change in CE shall be made after transmission of O-P-S YNCHR02. Any change in CE shall be made at the 
beginning of the DMT symbol (i.e. by changing the number of samples in Lcp). Windowing is applied at the transmitter, 
with the window length P set to the value specified in O-SIGNATURE (clause 8.2.4.2.1.1). The PSD mask is defined 
by network management. O-P-MEDLEY carries 2 octets of information (bisb^ .. bo) per DMT symbol mapped as 
described in table 81. The mapping of bits is as shown in figure 7. 

Table 81 : O-P-MEDLEY bit mapping 



Tone index 


Constellation point 


5, 10, 15, ...,5n, ... 


00 


1, 11,21, . 


.., 10n+1, . 




SOC message bits & 1 


2, 12,22, . 


.., 10n+2, . 




SOC message bits 2 & 3 


3, 13,23, . 


.., 10n+3, . 




SOC message bits 4 & 5 


4, 14,24, . 


.., 10n+4, . 




SOC message bits 6 & 7 


6, 16,26, . 


.., 10n+6, . 




SOC message bits 8 & 9 


7, 17,27, . 


.., 10n+7, . 




SOC message bits 10 & 1 1 


8, 18,28, . 


.., 10n+8, . 




SOC message bits 12& 13 


9, 19,29, . 


.., 10n+9, . 




SOC message bits 14 & 15 



The selected constellation points are pseudo-randomly rotated by 0, 7t/2, K, 3k/2 depending on the 2-bit random 
sequence provided by the pseudo-random bit generator defined in clause 8.2.4.2.2.1. Two bits are mapped onto each 
tone including DC. The pseudo-random bit sequence continues from one symbol to the next. The generator is reset only 
when the VTU-O enters the channel analysis and exchange state. 



8.2.6.2.2.2 



0-P-SYNCHR02 



0-P-SYNCHR02 is a wideband signal that allows the VTU-O and the VTU-R to simultaneously step into the 
Showtime State. It uses all of the allowed downstream tones modulated in 4QAM. The symbol length is N H- CE 
samples. N shall be set to the value specified during the handshake procedure and CE shall be set to the value specified 
in O-MSGl (clause 8.2.4.2.1.3). Windowing is applied at the transmitter, with the overall window length P set to the 
value specified in O-SIGNATURE (clause 8.2.4.2.1.1). The PSD mask is defined by network management. The 
duration of 0-P-SYNCHR02 is 15 DMT symbols. A fixed phase value of 1 1 is mapped on all the downstream tones for 
the first five and last five symbols. A fixed phase value of 00 is mapped on all the allowed downstream tones for the 
middle five symbols. The selected constellation points are pseudo-randomly rotated by 0, 7t/2, K, 3k/2 depending on the 
2-bit random sequence provided by the pseudo-random bit generator defined in clause 8.2.4.2.2.1. The pseudo-random 
bit sequence continues from one symbol to the next. The generator is never reset. In the downstream direction, the 
scrambler shall be disabled after the transmission of O-P-S YNCHROl. 



8.2.6.3 



Messages and symbols sent by the VTU-R 



8.2.6.3.1 



SOC messages 



During the channel analysis and exchange phase the VTU-R sends the SOC messages R-MSG2, R-CONTRACTl, 
R-MARGINl and R-B&G as well as the idle message R-IDLE. 

Clause 8.2.6.3.2 describes how the messages are modulated onto the transmit symbol. 
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8.2.6.3.1.1 R-MSG2 

This message contains information about the capabihties of the VTU-R for bit allocation. 

Table 82: Description of R-I\/!SG2 



Field 


Field or macro-field type 


Remark 


Message descriptor 


1 octet 


See table 49 


Maximum constellation size in upstream 


1 octet 


Maximum number of bits per tone 


RS setting supported by VTU-R 


1 octet 


0x00: only mandatory settings 
OxFF: all settings (see note 1) 


Interleaver setting supported by VTU-R 


1 octet 


0x00: only mandatory settings 
OxFF: all settings 
OxNN: NN = number of settings 
(0x00 < NN < OxFF) 


Detailed interleaver setting description 


octets if NN = 0x00 

octets if NN = OxFF 

NN X 4 octets otherwise 


See table 74 


Maximum power transmitted 


1 octet 


In units of 0,25 dBm 


Maximum interleaver memory 


3 octets 


In octets (see note 2) 


Maximum number of EOC octets per 
frame in upstream 


1 octet 


Number of EOC octets per frame 


Maximum number of VOC octets per 
frame in upstream 


1 octet 


Number of VOC octets per frame 


Support of express swapping 


1 octet 


0x00: Not supported 
OxFF: Supported 


J max 


1 octet 


Maximum value of jmax supported 
by the VTU-R (see note 3) 


NOTE 1 : All settings means the values (for the redundancy) that are specified in clause 6.4.2. 

NOTE 2: The interleaver memory is computed as Mxlx(l-1 ). 

NOTE 3: Specification of jmax = k means that all values from to k are supported. 



8.2.6.3.1.2 



R-C0NTRACT1 



This message contains the contract based on the maximum number of bits specified in 0-MSG2. The contract is 
encoded in a "Contract Descriptor" macro-field with all fields related to the fast channel set to 0x00. 



8.2.6.3.1.3 



R-MARGINn 



This message contains the margin computed by the VTU-R for the downstream contract proposed in O-CONTRACTn. 
Upon reception of R-MARGINn the VTU-O can decide to choose this contract by sending O-B&G or to propose a new 
contract by sending O-CONTRACTn. 

Table 83: Description of R-MARGINn 



Field 


Field or macro-field type 


Remark 


Message descriptor 


1 octet 




Margin 


1 octet 


In units of 0,5 dB 



8.2.6.3.1.4 



R-B&G 



R-B&G shall be used to transmit to the VTU-O the bits and gains information to be used in the downstream direction. 

The number of bits to be coded onto carrier / is denoted as bj. The gain scale factor that shall be applied to carrier / 
(relative to the gain used during the transmission of O-P-MEDLEY) is denoted as g. 

The bi and gi values are only defined for those tones that are used during the transmission of O-P-MEDLEY (i.e. the 
downstream tones indicated in O-SIGNATURE). Because no bits or energy will be transmitted at the other frequencies 
(at least in the opposite direction) the corresponding bj and gj values are all presumed to be set to zero and shall not be 
transmitted. 
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The bj and g; values shall be transmitted in ascending order (i.e. from lowest to highest tone). In case all bi values above 
a certain tone are zero, the remaining zero values do not have to be transmitted. The VTU-R shall assume that any 
missing values after the last received value correspond to tones that carry no bits. 



Each bi shall be represented as an unsigned 4-bit integer with a value in the range of zero to Bn 
maximum number of bits that the modem is prepared to modulate onto any sub-carrier. 



d which is the 



Each gi shall be represented as an unsigned 12-bit fixed-point quantity with the binary point assumed just to the right of 
the third most significant bit. For example a gi with binary representation (most significant bit listed first) 
001,0100000002 would instruct the modem to scale the constellation for carrier ; by a gain of 1,25 so that the power in 
that carrier shall be 1,94 dB higher than it was during O-P-MEDLEY. 

If use of a dedicated pilot tone, k, is required (see clause 5.1 .2.3. 1), the VTU-R shall indicate this requirement to the 
VTU-O by sending the value "2" in the position of bj^ in the bit table in R-B&G. In the gain table, it shall transmit a 
value of zero for the gain scaling of tone k. Receipt by the VTU-O of "2" in a bit table entry and zero in the 
corresponding gain scaling table entry indicates that tone has been selected as a dedicated pilot and shall be loaded with 
the 4QAM constellation point 00 during every symbol. 

The whole spectrum is split up into groups of adjacent tones such that the number of bits allocated to the carriers of a 
group is constant. The number of carriers in each group need not be constant but cannot exceed 256 carriers. The scale 
factor for each carrier within a group is defined by a polynomial interpolation. Only the parameters of the polynomial 
shall be transmitted. This polynomial is specified by means of the values of (jmax+1) defined tones where jn,ax is the 
order of the polynomial. The (jmax+1) tones are chosen to be equidistant. In the case of a group of carries [Xn, Xn+i] 
where Xn and Xn+i are the index of the lowest and highest tones respectively of the n-th group of carriers the (jmax+1) X„j 
positions are defined as: 



^nj =\ + 



jx{x„^i-xj 



in 



for j=0...j; 



At the VTU-O the value of jmax is chosen based on the values supported by the VTU-R as specified in R-MSG2. At the 
VTU-R the value of jmax is chosen based on the values supported by the VTU-O which are specified in 0-MSG2. 



An R-B&G message is defined as: 



Table 84: Description of R-B&G messages 



Field content 


Field or Macro-field type 


Message descriptor 


1 octet 


jmax 


1 octet 


bi and gi information 


B&G descriptor 



Table 85: B&G descriptor jmax=0 



Octet 



Content of field 



2n + 1 



2n + 2 



Specification of tone n + 1 for n = to N - 2 (see note) 

Bits - 3: number of bits bn 

Bits 4-15 scale gain gn 



NOTE: If tone n is not used the specification is not transmitted. 



Table 86: B&G descriptor jmax>0 and odd 



Octet 


Content of field 


1-2 


Nqr Number of group of tones 


3+ 1,5nX (jmax+1) 
3 + (n +1)X 1,5 X (jmax+1) 


Specification of tone in group n + 1 for n = to Ngr - 1 

Bits - 3: number of bits 

Bits 4-15: number of carriers of group n 

Bits 1 6 + 1 21 ^. 27 + 1 21: gx for tone X^j j = to jmax 
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Table 87: B&G descriptor jmax>0 and even 



Octet 


Content of field 


1-2 


Nqr Number of group of tones 


3 + 1 ,5n X {jmax+3) 

— > 
3 + (n + 1)x1,5x{jmax+3) 


Specification of tone in group n + 1 for n = to Ngr - 1 

Bits - 3: number of bits 

Bits 4-11: number of carriers of group n 

Bits 12 + 12i ^23-H 12i: gx for tone X^j j = Otojmax 



8.2.6.3.2 



Symbol types transmitted by the VTU-R 



8.2.6.3.2.1 



R-P-MEDLEY 



R-P-MEDLEY is a wideband signal used for estimation at the VTU-O of the upstream SNR. It uses all of the available 
upstream tones modulated in 4QAM. The symbol length shall be N H- CE samples. N shall be set to the value specified 
during the handshake procedure and CE shall be set to the value specified in O-MSGl (clause 8.2.4.2.1.3). Any change 
in CE shall be made at the beginning of the DMT symbol (i.e. by changing the number of samples in Lcp). Windowing 
is applied at the transmitter, with the overall window length P as specified in O-SIGNATURE (clause 8.2.4.2.1.1). The 
transmitter PSD mask shall meet the power back-off requirements. The timing advance is applied and corresponds to 
the loop length. R-P-MEDLEY carries two octets of information (bisb^ .. bg) & (bvbg .. bo) per DMT symbol mapped as 
described in table 88. 

Table 88: R-P-MEDLEY bit mapping 



Tone index 


Constellation point 


5, 10, 15, ...,5n, ... 


00 


1, 11,21, ..., 10n+1, . 




SOC message bits and 1 


2, 12,22, ..., 10n+2, . 




SOC message bits 2 and 3 


3, 12,23, ..., 10n+3, . 




SOC message bits 4 and 5 


4, 13,23, ..., 10n+4, . 




SOC message bits 6 and 7 


6, 16,26, ..., 10n+6, . 




SOC message bits 8 and 9 


7, 17,27, ..., 10n+7, . 




SOC message bits 1 and 1 1 


8, 18,28, ..., 10n+8, . 




SOC message bits 12 and 13 


9, 19,29, ..., 10n+9, . 




SOC message bits 14 and 15 



The selected constellation points are pseudo-randomly rotated by 0, 7t/2, n, 37t/2 depending on the 2-bit random 
sequence provided by the pseudo-random bit generator defined in clause 8.2.4.2.2.1. Two bits are mapped onto each 
tone including DC. The pseudo-random bit sequence continues from one symbol to the next. The generator is reset only 
when the VTU-O enters the channel analysis & exchange state. 



8.2.6.3.2.2 



R-P-SYNCHR02 



R-P-SYNCHR02 is a wideband signal that allows the VTU-O and the VTU-R to simultaneously step into the 
Showtime State. It shall use all of the allowed upstream tones modulated using 4QAM. The symbol length is Nh-CE 
samples where CE is set to the value specified in O-MSGl (clause 8.2.4.2.1.3) and N is negotiated during the 
handshake procedure. Windowing is applied at the transmitter and the overall window length (3 is set to the value 
specified in O-SIGNATURE (clause 8.2.4.2.1.1). The PSD shall conform with the UPBO requirements. The overall 
duration of R-P-SYNCHR02 is 15 DMT symbols. The value 1 1 is mapped on all the allowed downstream tones for the 
first five and the last five DMT symbols. The value 00 is mapped on the allowed downstream tones for the five 
remaining DMT symbols. The selected constellation points are pseudo-randomly rotated by 0, 71/2, 71 and 371/2 
depending on the 2-bit random sequence provided by the pseudo-random bit generator defined in clause 8.2.4.2.2.1. The 
pseudo-random bit sequence continues from one symbol to the next. 

The scrambler keeps free -running during the transmission of this R-P-S YNCHR02. In the upstream direction the 
quadrant scrambler shall be disabled after the transmission of R-P-S YNCHR02. 
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8.3 Single carrier activation/deactivation 
8.3.1 Link states and timing 

The Link State and Timing diagram presented in figure 57 is an implementation of the generic diagram presented in 
figure 49. It includes five states (rounded blocks), four types of link activation (rectangular blocks) and two types of 
link deactivation. Link activation and deactivation is initiated by Control signals described in clause 8.3.5. Both the 
VTU-O and VTU-R shall support all types of link activation and deactivation. 



/ Power-off 
( (Service Installation 
\. or change) 



No 

(Quiet) 



c 



Power Down 



Power-up 
Request 



Power-up 
Request 



Cold-Start 
(Timeout = T1) 



No 



Warm-Start 
(Time out = T2) 



c 



Applied if sync loss occurred in Idle! 
Yes Yes 

J L 

steady-State Transmission 



Idle 
Request 



Yes 



^"*^ Idle J 



Back-to-Service 
Request 




Warm- Resume 
(Time out = T4) 




Figure 57: Link State and Timing Diagram 



8.3.1.1 



States 



Power-off is the initial state intended for service installation and modification prior to the first power-up 
process; 

Steady-State Transmission (full duplex transmission) is a state achieved after the link activation process is 
completed. In this state the link shall transport user information with standard performance characteristics; 

Loss of Sync (Loss of Signal) is a state achieved if frame synchronisation loss occurs (also as a result of signal 
energy loss or symbol timing loss). During this state the link is interrupted. The link shall return from this state 
back to Steady-State Transmission if frame synchronisation is recovered in a short period of time (T5). 
Otherwise, the Resume-on-Error activation procedure will be invoked; 

Power Down is a state achieved after a guided power removal, power failure or QUIET deactivation at either 
the VTU-O or VTU-R. During this state the link is terminated. The link shall move from this state into the 
Warm-Start procedure by applying a Power-up request; 

Idle state (deactivated power save) provides an environment with a low generated crosstalk and a reduced 
power consumption when no broadband calls are in progress. After the VTU-O or VTU-R detects a broadband 
call wake -up signal (Back-to-Service request) from the network or from the CPE respectively, a Warm-Start 
procedure is executed. 
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NOTE: If the link connection is maintained during the Idle state, at least data frame synchronisation, VOC 
transparency and Sync Loss event monitoring shall be provided. The user data channels and EOC 
transparency is optional. If the link connection is not maintained during the Idle state, the Sync Loss 
event in the Idle state is not monitored. 

8.3.1.2 Activation 

• Cold-Start shall be applied after the first power-up or after an unsuccessful Warm-Start activation. If finished 
unsuccessfully, some changes in the installed service shall be made to simplify the link establishment. 

• Warm-Start shall be applied after an unsuccessful Resume-on-Error activation or an unsuccessful 
Warm-Resume activation or after either Power-down/Power failure or a link deactivation {QUIET) event. If 
finished unsuccessfully the Cold-Start activation is applied. 

• Resume-on-Error shall be applied after a link interruption due to loss of synchronisation, which was not self- 
recovered during the defined time out (T5). If finished unsuccessfully the Warm-Start activation is applied. 

• Warm-Resume shall be applied on receipt of a broadband call wake -up signal (Back-to-Service request 
command) if the link resides in the Idle mode. If finished unsuccessfully the Warm-Start activation is applied. 

NOTE 1 : Unsuccessful Cold-Start activation occurs usually if the activated link environment (attenuation, noise 
etc) can't provide the desired service. 

NOTE 2: Unsuccessful Warm-Start activation occurs usually after significant change of line characteristic (for 
example a connection to a new line with unknown parameters). 

NOTE 3: Unsuccessful Resume-on-Error activation occurs usually due to a temporary change of noise conditions 
in the loop or due to modification of the transmission parameters. 

NOTE 4: Unsuccessful Warm-Resume activation occurs usually due to a temporary change of noise conditions in 
the loop. 

NOTE 5: Back-to-Service request command may be applied at both the VTU-O and the VTU-R. 

Any of the defined activation processes conceptually includes the following steps: 

• Upstream and downstream channel equalisers convergence (PMD sub-layer activation); 

• Upstream and downstream channel transmission frame synchronisation (PMS-TC sub-layer activation); 

• Open the steady-state data communication between the VTU-O and VTU-R (TPS-TC sub-layer activation). 
In some particular cases of Resume-on-Error and Warm-Resume activation the equaliser convergence may be skipped. 

8.3.1.3 De-activation 

• QUIET shall terminate the link. QUIET shall be applied if power failure occurs, or if a transceiver restart is 
desired, or as a part of the power-down process. QUIET may be initiated while the link resides in any state or 
during any activation process. In any case, except the Cold-Start, after QWET de-activation the link shall be 
moved into the Power-Down state. QWET de-activation during the Cold-Start moves the link into the initial 
(Power-off) state. 

• Idle Request shall move the link into the Idle state. Idle Request may be applied on receipt of a broadband call 
release while the link resides in the Steady-State Transmission state only. 

NOTE: The Warm-Resume activation procedure is applied to return the link from the Idle state back to a 
Steady-State Transmission state. 
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8.3.2 Set of transmission parameters 



The required link transmission capabilities and characteristics are provided by the Set of Transmission Parameters 
(STP) presented in table 89. The STP applied at the VTU-O and VTU-R shall be the same, regardless of the state they 
reside in or the activation process they pass through. When the STP is modified in one VTU, the same change shall 
occur in the other one as well. 

Table 89: Set of Transmission Parameters 



Parameter 


Downstream 
carrier-1 


Downstream 
carrier-2 


Upstream 
carrier-1 


Upstream 
carrier-2 


Parameter Range 


Symbol Rate 


ID SR 


2D SR 


1U SR 


2U SR 


67,5 kBaud X N (N=1 , 2, ...) 


Constellation 


1D_C 


2D_C 


1U_C 


2U_C 


D C = 4 to 1 024 
U C = 4 to 1 024 


Centre Frequency 


ID CF 


2D CF 


1U CF 


2U CF 


In accordance with the applied 
transmission profile 


Transmit PSD 


ID PSD 


2D PSD 


1U PSD 


2U PSD 


Interleaving 
Parameters 


D_ M, D_l 


U_ M, U_l 


In accordance with tables 26 
and 27 of clause 6.5. 


Frame Format 


D FR 


U FR 



For the purpose of the present document a Current STP and a Standard STP are defined. 

8.3.2.1 Current STP 

The Current STP (CR_STP) contains transmission parameters currently in use by the upstream and downstream 
transmitters. 



8.3.2.2 



Standard STPs 



The following five standard STPs are defined to provide interoperability between transceivers from different vendors. 
The standard STPs are permanently stored in both the VTU-O and VTU-R local Activation Data Base and shall be 
applied to perform the corresponding activation/deactivation procedures. 

• Default STP (DF_STP) shall be applied to perform a Cold-Start activation. Usually DF_STP parameter values 
are set by the network operator at the VTU-O prior to system installation and may be delivered to the remote 
side by the handshaking procedure. Alternatively, the DF_STP may be set prior to system installation at the 
both sides. The DF_STP shall be kept constant until the link is returned into Povver-Oj^ state to change the type 
of service. The parameter values for DF_STP providing interoperability for either the VDSL band allocation or 
the optional regional specific band allocation are shown in table 90. The nominal PSD value of the default STP 
(DF_STP) shall meet the requirements specified in TS 101 270-1 [1]. 

Table 90: Default values of DF STP 



Parameter 


ID 


2D 


1U 


2U 


Symbol Rate (MBaud) 


0,57375 
(17x0,03375) 





0,7425 
(22 X 0,03375) 





Constellation 


4 




4 




Centre Frequency (IVIHz) 


1,45125 
(86x0,016875) 




4,455 
(264x0,016875) 




Transmit PSD (dBm/Hz) 


-61 




<-61 (note 1) 


^ 


Interleaver 


Disabled 


Frame Format 


Type [0/0] (single latency) 


NOTE: The value will be decreased upon application of upstream power back-off. 



Warm-Start STP (WS_STP) shall be applied to perform a Warm-Start activation. WS_STP initially shall be set 
equal to the DF_STP. A VOC communication may be used to negotiate changes to WS_STP. 

Warm-Resume STP (WR_STP) shall be applied to perform a Warm-Resume activation. As the link enters 
Steady-State Transmission state WR_STP shall be automatically set equal to the currently applied CR_STP. 
The WR_STP settings shall be complete prior to an Idle deactivation. 
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Resume-on-Error STP (RE_STP) shall be applied to perform a Resume-on-Error activation. As the link enters 
either Steady-State Transmission state or Idle state and during these states RE_STP is automatically set equal 
to the currently applied CR_STP. The RE_STP settings shall be complete prior to a Resume-on-Error 
activation. 

Idle STP (I_STP) - optional - shall be applied to perform a transition to the Idle state. The I_STP initially shall 
be set equal to CR_STP, except for constellation size, which is set to 4, and the transmit PSD level, which may 
be reduced by the values presented in table 91. A VOC communication may be used to negotiate changes to 
I_STP. All changes in I_STP shall be complete prior to an Idle deactivation. 

Table 91 : Constellation size at start-up 



Steady-state transmission constellation 


4 


8 


16 


32 


64 


128 


256 


512 


1 024 


Maximum PSD reduction, dB 


3 


7 


10 


12 


12 


12 


12 


12 


12 



NOTE 1: Other DF_STP are for further study. 

NOTE 2: If I_STP is not defined, the system could be moved into the Idle state by a generic CR_STP modification, 
as described in clause 8.3.3.2. 

8.3.3 Transmission parameters modification 

At the discretion of the network operator, transmission parameter settings for CR_STP and all standard STPs, except 
DF_STP, can be modified, as appropriate for the required service characteristics. The modification of STP can be 
initiated only by the VTU-O. The VTU-R is not required to accept the requested value of a transmission parameter if it 
is not a standard setting. 

NOTE: DF_STP may be changed during the system re-installation or by re-applying the handshake procedure 
prior the Cold-start, or by some vendor proprietary procedure, which is beyond the scope of the present 
document. 



8.3.3.1 



Adjustment of standard STP values 



From the standard STPs only WS_STP and I_STP may have individual parameter values modified under the control of 
the VTU-O. The parameter values for the STP can be modified during the Steady-State Transmission state of the link 
only. 

The VTU-O gets the new settings for the intended STP target from the local management system. It shall send to the 
VTU-R through the VOC a copy of the new STP and a request to make the corresponding changes to its own copy of 
the corresponding STP. Once accepted by the VTU-R the new STP settings are stored at both the VTU-O and VTU-R. 

The RE_STP shall be automatically updated to be equal to the currently applied CR_STP each time the link enters 
Steady-State Transmission state or Idle state. Similarly, WR_STP shall be automatically updated to be equal to the 
currently applied CR_STP each time the link enters Steady-State Transmission state. 

8.3.3.2 CR_STP adjustment 

The CR_STP parameter values may be modified in two different ways. 

• The CR_STP shall be automatically overwritten with DF_STP, WS_STP or RE_STP when the link, enters 
Cold-Start, Warm-Start or Resume-on-Error, respectively. During these changes the link is usually interrupted 
or disconnected. 

• The CR-STP shall be overwritten with a new setting after a successful communication of a VOC trigger 
message (CHANGE, BTSERVC or IDLEREQ) followed by a trigger handshake. The procedure shall be used 
both to make generic modifications to CR_STP, and to modify CR_STP to I_STP or to WR_STP upon 
transition into Idle state or entering Warm-Start respectively. The CR_STP modification is initiated by a 
special control signal from the VTU-O (CHNG_PRM, B_SERV or I_REQ) and can be performed only during 
the Steady-State Transmission link state, except for CR_STP to WR_STP modification, which is made during 
the Idle state. The modification of CR_STP is accompanied by corresponding changes in both 
transmitter/receiver parameters and in transmit signal parameters, as defined by the new CR_STP. 
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For a generic parameter modification, the STP modification requests and the new parameter settings come to the 
VTU-R from the VTU-O over the VOC. After all the new parameter settings are successfully communicated, the 
VTU-O management system uses a CHANGE VOC message to request that CR_STP be overwritten with the new 
parameter settings. A special trigger handshake activated after the successful communication of the CHANGE message 
overwrites CR_STP, RE_STP at both the VTU-O and the VTU-R with the new parameter settings and triggers the 
desired change in their transmitter/receiver parameters. 

For transitions into the Idle state or for Warm-Resume activation, CR_STP and RE_STP are overwritten with I_STP or 
WR_STP respectively in the same manner, after the successful communication of IDLEREQ or BTSERVC VOC 
messages followed by a trigger handshake. 

If due to the performed parameter change the link moves into the Loss of Sync state (caused by symbol rate change, for 
example), it will either recover synchronisation within time T5 and thereby return to Steady-State Transmission state 
with new parameters in place, or instead it will attempt a Resume -on- Error activation with RE_STP equal to the 
modified CR_STP. If this Resume-on-Error activation is successful, the link returns to Steady-State Transmission with 
the successfully accomplished parameter change. If not, the parameter change process has failed, and Warm-Start 
activation is automatically attempted to return the link into the Steady-State Transmission state. 

NOTE: With some additional delay, a generic CR_STP modification can also be effected without use of the 
CHANGE VOC command and the trigger handshake. The technique is to use the VOC to set the new 
desired transmission parameters into WS_STP, then force a Warm-Start by deactivating the link through 
application of the QUIET control signal at either end of the link and then activating the link back. 
Failure to acquire the link with the new parameter values automatically initiates a Cold-Start and thus the 
link will be returned into the Steady-State Transmission state for the next parameter modification attempt 

8.3.3.3 STP adjustment summary 

A summary of the STP modification rules is presented in table 92. 

NOTE: All the listed STP modifications are fully provided by the VTU-O, VTU-R state machines described in 
clause 8.3.9. 

Table 92: Summary of STP Modification Rules 



Parameter 


Overwritten automatically: 


Overwritten by the operator: 


DF STP 


N/A 


N/A 


WS STP 
1 STP 


N/A 


with an arbitrary parameter setting during 
Steady-State Transmission state 


WR_STP 


with the CR_STP upon entry to Steady-State 
Transmission state. 


N/A 


RE_STP 


with the CR_STP upon entry to either 
Steady-State Transmission or Idle state; 
with the CR_STP, immediately after CR_STP 
was overwritten with the new parameter settings 
(1 STP, WR STP or generic). 


N/A 


CR_STP 


with the DF_STP, WS_STP, or RE_STP at the 
beginning of a Cold-Start, Warm-Start, or 
Resume-on-Error activation, respectively. 


with an arbitrary transmission parameter setting 
during the Steady-State Transmission, after a 
successful communication of the CHANGE VOC 
message followed by a trigger handshake (generic 
CR_STP modification); 

with l_STP upon entering Idle state after a successful 
communication of the IDLEREG VOC message 
followed by a trigger handshake (moving into Idle 
state); 

with WR_STP upon entry to the Warm-Start, after a 
successful communication of the BTSERVC VOC 
message followed by a trigger handshake (moving 
back from /d/e state to Steady-State Transmission); 



ETSI 



140 



ETSI TS 101 270-2 VI .2.1 (2003-07) 



8.3.4 VTU activation/deactivation 

The VTU- activation/deactivation functional diagram is shown in figure 58. The activation/deactivation process is 
performed by the VTU state machine described in clause 8.3.9. Prior to activation, the VTU state machine shall be 
supplied with the appropriate CR_STP to be used in the activation. This STP stored in CR_STP Memory (CR_STPM) 
of the VTU Activation database. The VTU management entity shall load the appropriate standard STP (DF_STP, 
WS_STP, or RE_STP) or a generic STP into the CR_STPM for the subsequent activation type. Thus it supports the 
desired link characteristics and all the required activation types, as defined in figure 57. 

The activation/deactivation is driven by the Control signals originated by the VTU management entity, which shall also 
monitor the state machine states and flags. 



VTU management entity 



VOC Communication Entity 



State Macliine Control 



State Macliine Monitoring 



Control Signals i\ U 



Memory management 



t Y t t t 



State Macliine 




CR_STP 



U U 



CR_STP Memory 
(CR_STPM) 



Standard STP Memory 
(RE_STP, WS_STP, Dr_STPetc) 



Activation Data Base 



Figure 58: VTU- Activation/Deactivation Functional Diagram 

The CR_STPM shall contain the STP for the pending activation process. Identical STP shall be loaded into the 
CR_STPM at both the VTU-O and VTU-R at the start of the activation and kept constant until the activation process is 
complete, either successfully or not. If the activation process is successfully completed the loaded CR_STP will be used 
during the following steady-state transmission until a new parameter modification request. If any activation process 
fails, a new STP will be automatically loaded into CR_STPM in accordance with the next activation type, as described 
in figure 57. 

8.3.5 Control signals 

The VTU activation/de-activation process shall be driven by the following Control signals: 

• Connect (CON) - to initiate the activation process after the link was disconnected (i.e. initiates either 
Cold-Start or Warm-Start). As Connect is set, the VTU shall move from the STANDBY state to start the link 
synchronisation. Applied at the VTU-R in the case of activation from the CPE site, and at the VTU-O in the 
case of activation from the ONU/CO site. Connect is ignored in all states except STANDBY. 

• Quiet (QUIET) - to terminate the link. As QUIET is set, the activated transceiver shall move from its current 
state into the POWER_UP state. Applied for transceiver restart or as a part of the power-down process. 
QUIET is applicable for both the VTU-O and VTU-R. 

• Change parameter (CHNG_PRM) - to initiate a generic parameter modification process. Applied only at the 
VTU-O while the link is in a Steady-State Transmission state. 
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• Idle Request (I_REQ) - optional - to initiate the link deactivation into the Idle state. As Idle Request is set, the 
hnk shall move from the Steady-State Transmission into the Idle state. Applied only at the VTU-O while the 
link is in the Steady-State Transmission state. 

• Back-to-Service (B_SERV) - to initiate a Warm-Resume activation. As Back-to-Service is set the link shall 
move from the Idle state into the Steady-State Transmission state. Applied for both the VTU-O and VTU-R 
while the link is in the Idle state. 

• Disconnect (DISCON) - optional - to disable the link activation attempt (CON signal) from the VTU-R. Used 
to prevent uncontrolled link activation. Applied at the VTU-O only. 



8.3.6 Flags and indicators 



The local VTU management entity uses Flags and Indicators to monitor the state machine. The state machine shall 
provide the following Flags and Indicators for monitoring purposes. 

• State Indicator (ST) - to indicate the current state of the state machine. Used by the VTU management entity to 
set or reset user data and EOC throughput. 

• Complied Flag (CF) - to indicate that the last command being applied by a certain Control signal was 
successfully executed. 

• Unable-to-Comply Flag {UTCF) - to indicate that the last command being applied by a certain Control signal 
was not executed. 

• Remote-Activation-Request Flag (RAF) - to indicate that an activation request from the VTU-R have been 
received, applicable at the VTU-O while in STANDBY state only. 

• Back-to-Service-Request Flag {BTSF) - indicates that a back-to-service request from the VTU-R have been 
received, applicable at the VTU-O while the link is in Idle state only. 



8.3.7 Transmit signals 



For each state of the VTU state machine, during both the activation and steady-state transmission, is specified a transmit 
signal, while residing in that state. All transmit signal types are presented in table 93. 

Transmit signals 0_QUIET and R_QUIET shall drive the line with zero volts (silence). Other transmit signals shall be 
formatted as a standard transmission frame (see clause 7.3.1.6) and specified by the contents of the OC field and by the 
values of o_trig, r_trig and rjlag signals (see table 23), and by the values of indicators IB-7 to IB-9 (see table 24). 

Signals 0/R_ ACQUIRE, 0/R_TRIG always carry the IDLE VOC message; signals 0/R_DATA can carry both IDLE 
and valid VOC and EOC messages. 

The o_trig bits in the downstream transmission frame header are equal one for the 0_TRIG signal and zero for all other 
VTU-O transmit signals. The r_trig bit equals for all VTU-R transmit signals, except for R_TRIG, where it is set to 1. 
The rJlag is set to in all signals except R_DATA, in which it is set to 1 once the B_SERV control signal is applied at 
the VTU-R. 
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Table 93: Transmit Signals Summary 



Signal 


OC Field 


Control Field 


Note 


QUIET 




No transmission 




0_ACQUIRE 


QC = IDLE 


trig = 0, 
IB-9 = 1 


User Data: Denied 
EQC: Denied 


0_TRIG 


QC = IDLE 


trig = 1 , 
IB-9 = 


User Data: Applicable 
(see note 1) 
EQC: Denied 


0_DATA 


QC = valid message 


trig = 0, 
IB-9 = 


User Data: Applicable 

(see note 1) 

VQC: Applicable 

EQC: Applicable (see note 1) 


R QUIET 




No transmission 




R_ACQUIRE 


OC = IDLE 


rjrig = 0, 
r flag = 0, 
IB-7 = 1 


User Data: Denied 
EQC: Denied 
Variable transmit level 
(see note 2) 


R_TRIG 


QC = IDLE 


rJrig = 1 , 
r flag = 0, 
IB-7 = 


User Data: Applicable 
(see note 1) 
EQC: Denied 


R_DATA 


QC = valid message 


r trig = 0, 
r flag = 0/1 , 
IB-7 = 


User Data: Applicable 

(see note 1) 

VQC: Applicable 

EQC: Applicable (see note 1) 


NOTE 1 : Optional, if the link is in Idle state. 

NQTE 2: To support the upstream Start-up power bacl<-off process during the Cold-Start. 
NQTE 3: During transmission of signals 0/R_DATA the indicator bits IB-7, IB-8, and IB-9 show 
temporary loss of synchronisation when all are set to 1 . 



8.3.8 Timers 

The following timers, listed in table 94 are involved in the VTU- activation/de-activation process. 

Table 94: VTU State-Machine Timers 



Timer 


Function 


Value 


tp_0 


Duration of the R QUIET signal detection at VTU-Q to 
complete the Q PQWERUP state. 


100 ms 


tp_R 


Duration of the QUIET signal detection at VTU-R to 
complete the R PQWERUP state. 


100 ms 


tl R 


DS equaliser convergence time-out 


4s 


tl 


US equaliser convergence time-out 


4s 


t2_0 
t2_R 


Time-out for VTU-Q activation process 
Time-out for VTU-R activation process 


Depends on start-up type: 

T1 for Cold-Start, 

T2 for Warm-Start, 

T4 for Warm-Resume, 

T3 for Resume-on-Error, 

T3 + T5 following CHANGE VQC message 


h 


Time-out for VTU-Q trigger handshake 


1 000 ms 


h R 


Time-out for VTU-R trigger handshake 


100 ms 


t4 


Time-out to recover VTU-Q frame synchronisation 


200 ms 


t4R 


Time-out to recover VTU-R frame synchronisation 


200 ms 


NQTE: Tl to T5 are defined in Parti of this specification and also appear in figure 49. 
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8.3.9 VTU-0 state machine 

The VTU-O state machine is shown in figure 59. 

NOTE 1 : Each elHpsoid block in figure 59 represents a state which contains the state number (SI -^ S7) followed 
by the state name. The names of the VTU-O transmit signal, while residing in that state, is placed below 
the state name. 

SI: 0_POWERUP 

This state is the initial state of the state machine. It corresponds to the start of the activation process and shall be entered 
in the following cases: 

a QUIET Control signal or a Power-up request is applied. This is the first step in a pending Cold-Start or 
Warm-Start activation, as shown by figure 57. 

Loss of Upstream Signal {US_LOS) is detected while in states S3 - S4 or time-out of states S3 - S4. This SI 
entry follows a failed activation attempt and is the first step in a pending reactivation attempt of type specified 
by figure 57. 

In state SI, the VTU-O shall transmit 0_QUIET. The VTU-O transmitter and receiver shall be configured with the STP 
stored in CR_STPM. 

The VTU-O transits into state S2 if loss of the received upstream signal (US_LOS) is detected for more than tp o ms. 

NOTE 2: The definition for los given in clause 7.3.1.3 shall be used for US_LOS. 

S2: 0_STANDBY 

In state S2 the VTU-O shall transmit 0_QUIET and wait for an activation request, which could be either the Connect 
Control signal, if the link is activated from the VTU-O, or detection of the upstream received signal energy {Disconnect 
Control signal disabled), if the link is activated from the VTU-R. Once the activation request is performed the timer to 
shall be started from zero and state S3 shall be entered. 

The Disconnect Control signal shall override any activation request from the VTU-R. If QUIET is applied while in this 
state, the VTU-O is returned to state SI. 

NOTE 3: The timer to, started at the beginning of VTU-R activation, is used to monitor the VTU-R synchronisation 
process. 

S3: 0_CONVERGE 

In state S3 the VTU-O shall transmit the 0_ACQUIRE signal while attempting to converge the upstream equaliser(s). 
The IB-9(rdi) bit shall be set 1 to indicate that the upstream direction is not synchronised. This state is entered from 
state S2 following an activation request, or from state S6 following a non recovered synchronisation loss (including that 
due to a change in the current upstream transmission parameters through the CHANGE VOC message). The transition 
from S6 to S3 corresponds to the initiation of a Resume-On-Error activation attempt. 

NOTE 4: The converging process includes identification of the received US signal shaping type (whether BSS or 
PSS). 

The VTU-O shall converge its upstream equaliser(s) before the timer to reaches tj.o ms. If convergence is not achieved 
within this time the VTU-O shall return to state SI. If convergence is reached before this time, the VTU-O shall 
immediately transit to state S4, without waiting for the full time-out period to elapse. 

If QUIET is applied or if US_LOS occurs while in this state, VTU-O shall return to state SI. 
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LOS/LOF&t4_o 



Equalizer Converged 




Figure 59: VTU-0 Activation/De-activation State Machine 



S4: O FINDFRAME 



While in state S4 the VTU-O shall transmit 0_ACQUIRE and o_pmd_rai bit shall be set 1 to indicate that the upstream 
direction is not synchronised yet. In state S4 the VTU-O shall process the received upstream bit stream to acquire the 
upstream transmission frame using the Frame Delineation Algorithm (see clause 6.5.1.5). The VTU-O shall transit to 
state S5 as soon as the frame acquisition is complete and stable for at least 100 ms. If frame acquisition is not complete 
before ty reaches t2.o ms, or if QUIET is applied, or if US_LOS occurs while in this state, the VTU-O shall return to state 
SI. 

S5: 0_ACTIVE 

The VTU-O shall reside in this state while the upstream channel is acquired. While in S5 the VTU-O shall transmit 
0_DATA; the state of the link is either Steady-State Transmission or Idle. 

In S5 the VTU-O may transmit VOC messages to modify CR_STP, WS_STP or I_STP if required by the VTU-O 
management entity. If the link state is Idle, the VTU-O also tracks the Back-to-Service request from the VTU-R by 
monitoring the r_flag bits in the received transmission frame header. After r_flag = 1 is detected, the VTU-O shall 
transmit the BTSERV VOC message to confirm the request. If the BTSERV message is transmitted successfully, the 
B_SERV Control signal shall be applied to initiate the state machine to move the link from the Idle state back to the 
Steady-State Transmission state. 

To perform a generic CR_STP modification the VTU-O management entity shall apply CHNG_PRM Control signal, 
which causes the VTU-O to transmit VOC messages containing the new desired values of transmission parameters. 
Once all the necessary new parameter values are successfully transmitted (no ECHO response from the VTU-R on the 
requested parameter change is UTC), the VTU-O shall transmit a CHANGE VOC message, which confirms that both 
the VTU-O and VTU-R are ready to change their transmission parameters for a new parameter setting. After the 
CHANGE message is transmitted successfully, the VTU-O shall wait for reception of the upstream signal R_TRIG by 
monitoring the r_trig bits in the received transmission frame header. Once the received value r_trig = 1 is detected, the 
VTU-O shall move to state S7. 

If the VTU-O is in Idle state and a B_SERV Control signal is applied (initiated either by the VTU-O or upon r_flag = 1 
reception), the VTU-O shall transmit a BTSERVC VOC message, which confirms than both the VTU-O and VTU-R 
are ready to change their transmission parameters with WR_STP to return the link back to the Steady-State 
Transmission state from the Idle state. After the BTSERVC message is transmitted successfully, the VTU-O shall wait 
for reception of the upstream signal R_TRIG by monitoring the r_trig bits in the received transmission frame header. 
Once the received value r_trig = 1 is detected, the VTU-O shall move to state S7. 
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If the VTU-O is in Steady-State Transmission state and an I_REQ Control signal is applied, the VTU-O shall transmit a 
IDLEREQ VOC message, which confirms than both the VTU-O and VTU-R are ready to change their transmission 
parameters with I_STP to pull the link into the Idle state from the Steady-State Transmission state. After the IDLEREQ 
message is transmitted successfully, the VTU-O shall wait for reception of the upstream signal R_TRIG by monitoring 
the r_trig bits in the received transmission frame header. Once the received value r_trig = 1 is detected, the VTU-O 
shall move to state S7. 

If R_TRIG reception is not achieved in t3.o ms after any CHANGE, BTSERVC or IDLEREQ message is transmitted 
successfully the VTU-O shall make no changes in CR_STP and shall remain in ACTIVE state. 

If los or sef occurs while in this state, the VTU-O shall transit to state S6. If QUIET is applied the VTU-O shall return to 

state SI . 

S6: 0_SYNC LOSS 

In this state the VTU-O attempts to recover the lost transmission frame synchronisation. After the synchronisation is 
recovered the VTU-O shall return to state S5. If synchronisation is not recovered during the time-out interval of t4.o ms, 
the VTU-O shall move to state S3 to initiate a Resume-On-Error activation request. The VTU-O shall move to state SI 
if QUIET is, applied. During this state 0_ACQUIRE shall be transmitted to inform the VTU-R on the VTU-O 
synchronisation loss by setting IB-9(rdi) = 1. 

S7: 0_TRIGGER 

In state S7 the VTU-O shall transmit the 0_TRIG signal with o_trig = 1 for 50 ms ± 1ms. Following this the VTU-O 
shall overwrite CR_STP with a new parameter setting, with WR_STP, or with I_STP depending on whether the 
CHANGE, BTSERVC or IDLEREQ VOC message, respectively, was last transmitted. Then the VTU-O shall make the 
corresponding changes to it's transmitter/receiver parameters, and returns to state S5 with a new CR_STP parameter 
setting. Upon entering S5 RE_STP shall be automatically overwritten with CR_STP. 

If QUIET is applied, the VTU-O shall return to state S 1 . 

NOTE 5: The transmission of o_trig is used to synchronise transmission parameter modification at the VTU-R with 
the same modification at the VTU-O. The timing diagram of the VTU-O to VTU-R interaction during the 
0/R_TRIG state is presented in figure 60. In accordance with figure 60, the VTU-R executes the 
parameter change after the point "C" and the VTU-O executes the parameter change after the point "D". 
The maximum difference between parameter modification at the VTU-O and VTU-R doesn't exceed 
50 ms (omitting execution time). 



Vru-R state S5 A S7 A S5 



r_trig 



® 



© 






50 ms 



VTU-O state S5 A S7 h 85 



Trigger Transitions: 

A) CHANGE/BTSERVC/IDLEREQ VOC confirmed, VTU-R enters state S7. 

B) CHANGE /BTSERVaiDLEREQ VOC confirmed, VTU-O detects r_trig = 1 , VTU-O enters state S7. 

C) VTU_R detects o_trig = 1 and enters S5. 

D) 50 ms after entering S7, VTU-O enters S5. 

Figure 60: Trigger Transitions Following CHANGE/BTSERV/IDLEREQ VOC Message 
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8.3.1 VTU-R state machine 

The VTU-R state machine is shown in figure 61. The conventions for interpreting this figure are the same as those 
described for figure 59. 

SI: R_POWERUP 

This state is the initial state of the state machine. It corresponds to the start of the process and shall be entered in the 
following cases: 

a QUIET Control signal or a Power-up request is applied. This is the first step in a pending Cold-Start or 
Warm-Start attempt, as shown by figure 57. 

Loss of Downstream Signal {DS_LOS) is detected while in states S3 - S4, time-out of states S3 - S4. This SI 
entry follows a failed activation attempt and is the first step in a pending reactivation attempt of type specified 
by figure 57. 

In state SI the VTU-R shall transmit R_QU1ET. The VTU-R transmitter and receiver shall be configured with the STP 
stored in CR_STPM. 

The VTU-R transits into state S2 if loss of the received downstream signal (DS_LOS) is detected for more than in tp r 
ms. 

NOTE 1: The definition for los given in clause 7.3.1.3 shall be used for DS_LOS. 

S2: R_STANDBY 

In state S2 the VTU-R shall transmit R_QUIET and wait for an activation request, which could be either the Connect 
Control signal, if the link is activated from the VTU-R, or detection of the downstream received signal energy, if the 

link is activated from the VTU-O. Once the activation request is performed the timer t j^ shall be started from zero and 

state S3 is entered. If QUIET is, applied while in this state, the VTU-R shall return to state SI. 

NOTE 2: The timer Ir, started at the beginning of VTU-O activation, is used to monitor the VTU-O synchronisation 
process. 



L0S/L0F&t4_r 



Equalizer Converged 




Figure 61 : VTU-R Activation/Deactivation State Machine 
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S3: R_CONVERGE 

In state S3 the VTU-R shall transmit the R_ACQUIRE signal while attempting to converge the downstream 
equaliser(s). The IB-9(rdi) bit shall be set 1 to indicate that the downstream direction is not synchronised. This state is 
entered from state S2 following an activation request, or from state S6 following a non recovered synchronisation loss 
(including that due to a change in the current downstream transmission parameters through the CHANGE VOC 
message). The transition from S6 to S3 corresponds to the initiation of a Resume-On-Error activation attempt. 

NOTE 3: The converging process includes identification of the received DS signal shaping type (whether BSS or 
PSS). 

The VTU-R shall converge its downstream equaliser(s) before the timer t^ reaches tj.R ms. If convergence is not 
achieved within this time the VTU-R shall return to state SI. If convergence is reached before this time, the VTU-R 
shall immediately transit to state S4, without waiting for the full time-out period to elapse. 

If QUIET is applied or if DS_LOS occurs while in this state, the VTU-R shall return to state SI. 

If state S3 is entered from state S2 upon activation request for a Cold-Start an upstream power back-off (US_PBO) 
procedure shall be applied. Upon entering state S3 the VTU-R shall start to transmit R_ACQUIRE signal at a reduced 
power level (the level is for further study). At the start of the downstream equaliser convergence process the received 
downstream signal will be measured and the R_ACQUIRE signal power level shall be raised to the nominal value, 
including the upstream power back-off. The functional diagrams describing activation from both the VTU-O and the 
VTU-R are presented in figures 62 and 63. 
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Figure 62: Activation From the VTU-O 
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Figure 63: Activation From the VTU-R 



S4: R FINDFRAME 



While in state S4 the VTU-R shall transmit R_ ACQUIRE and IB-9(rdi) bit shall be set 1 to indicate that the 
downstream direction is not synchronised yet. In state S4 the VTU-R shall process the received downstream bit stream 
to acquire the downstream transmission frame using the Frame Delineation Algorithm (see clause 6.5.1.5). The VTU-R 
shall transit to state S5 as soon as the frame acquisition is complete and stable for at least 100 ms. If frame acquisition is 
not complete before t^ reaches t2.R ms, or if QUIET is applied, or if DS_LOS occurs while in this state, the VTU-R shall 
return to state SI . 

S5: R_ACTIVE 

The VTU-R resides in this state while the downstream channel is acquired. While in S5 the VTU-R shall transmit 
R_DATA, the link state is either Steady State Transmission or Idle. 

In S5 the VTU-R may receive VOC messages which deliver modified transmission parameters values for CR_STP, 
WS_STP or I_STP, as directed by the VTU-O. If a B_SEKV Control signal is applied the VTU-R shall transmit 
r_flag = 1 and shall wait for the successful reception of the BTSERV VOC message, which confirms that the B_SERV 
signal applied in the VTU-R was received by the VTU-O. 

If the VTU-R successfully receives the CHANGE, BTSERVC, or IDLEREQ VOC messages, it shall transit to state S7. 

If los or sef occurs while in this state, VTU-R shall transit to state S6. If QUIET is applied VTU-R shall return to 

state SI . 

S6: R_SYNC LOSS 

In this state the VTU-R attempts to recover the lost transmission frame synchronisation. After the synchronisation is 
recovered the VTU-R shall return back to state S5. If synchronisation is not recovered during the time-out interval of 
t4_r ms, the VTU-R shall move to state S3 to initiate a Resume-On-Error activation request. The VTU-R shall move to 
state SI if QUIET is applied. During this state R_ ACQUIRE is transmitted to inform the VTU-O on the VTU-R 
synchronisation loss by setting IB-9(rdi) = 1. 
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S7: R TRIGGER 



In state S7 the VTU-R shall transmit the R_TRIG signal with r_trig = 1 and shall monitor the o_trig bit in the received 
transmission frames. Once o_trig = 1 is detected, the VTU-R shall overwrite CR_STP with a new parameter setting, 
with WR_STP, or with I_STP, depending on whether the CHANGE, BTSERVC or IDLEREQ VOC message, 
respectively, was last transmitted. Then the VTU-R shall make the corresponding changes to its transmitter/receiver 
parameters, and shall return to state S5 with a new CR_STP parameter setting. Upon entering S5 RE_STP shall be 
automatically overwritten to CR_STP. If o_trig = 1 is not detected within the time-out interval of ts.R ms after entering 
state S7, the VTU-R shall return to state SI. 

If QUIET is applied the VTU-R shall return to state SI. 

8.3.1 1 Two-step activation 

Both the VTU-O and the VTU-R may support a two-step activation process. 

Step 1 : Activation with 4-point constellation; 

Step 2: Modifying the constellation size using a standard CR_STP procedure. 

The standard two-step activation shall use the activation diagram described in clause 8.3 and the standard VTU state 
machine described in clause 8.3.9. It shall be performed in the following sequence: 

7) Start the link and reach steady-state transmission with DF_STP. 

8) Select the required transmission profile by sending a PROFILE command with bit D3 set. 

9) Change the selected profile from DF_STP to CR_STP using the CHANGE command and reach steady-state 
transmission. 

10) Use the CONSTEL command to specify the desired constellation size. 

11) Activate the modified CR_STP profile using the CHANGE command and reach steady-state transmission. 

NOTE 1 : Performance monitoring VOC messages are allowed to be inserted between the specified parameter 
setting messages. 

NOTE 2: If the VTU-R can only be activated using the two-step approach, the constellation size for the WS_STP 
profile shall be fixed to QAM-4. 
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Annex A (informative): 

UTOPIA Implementation of the ATIVI-TC Interface 

This annex describes the implementation of the interface between the ATM-specific TPS-TC Sublayer and ATM Layer 
at the VTU-O, called, y-O, interface in the VDSL reference model. The implementation is also applicable to the 
VTU-R. 
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Figure A.1 : Interfaces to ATM TPS-TC Sublayer, internal to ATM VTU-O 

The ATM Layer performs cell multiplexing from and de-multiplexing to the appropriate physical port (i.e. latency path 
- fast or slow) based on the Virtual Path Identifier (VPI) and Virtual Connection Identifier (VCI), both contained in the 
ATM cell header. The ATM Layer management configures the cell de-multiplexing process. 

An ATM TPS-TC Sublayer is provided for each latency path separately. ATM TPS-TC functionality is described in 
clause 6.2.1. 

The logical input and output interfaces at the reference point y-O for ATM transport is based on the UTOPIA Level 2 
interface with cell level handshake. The logical interface is given in tables A.l and A.2 and shown in figure A. 1. When 
a flow control flag is activated by the VTU-O (i.e. the VTU-O wants to transmit or receive a cell), the ATM layer 
initiates a cell Tx or cell Rx cycle (53 byte transfer). The VTU supports transfer of a complete cell within 53 
consecutive clock cycles. The UTOPIA Tx and Rx clocks are mastered from the ATM layer. The same logical input and 
output interfaces based on the UTOPIA Level 2 interface can be used at the y -R reference point in the VTU-R. 
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Table A.1 : UTOPIA Level 2 ATM Interface Signals for Tx 



Signal Name 


Direction 


Description 


Transmit Interface 


TxClk 


ATM to PHY 


Timing signal for transfer 


TxClav[0] 


PHY to ATM 


Asserted to indicate that the PHY Layer has buffer space 

available to receive a cell from the ATM Layer 
(de-asserted 4 cycles before the end of the cell transfer) 


TxEnb* 


ATM to PHY 


Asserted to indicate that the PHY Layer must sample and 
accept data during the current clock cycle 


TxSOC 


ATM to PHY 


Identifies the cell boundary on TxData 


TxData[7..01 


ATM to PHY 


ATM Cell Data transfer (8-bit mode) 


TxAddr[4..0] 


ATM to PHY 


PHY device address to select the device that will be active or 
polled for TxClav status 


TxRef* 


ATM to PHY 


Network Timing Reference (8 kHz timing signal) 
(only aty-0 interface) 



Table A.2: UTOPIA Level 2 ATM Interface Signals for Rx 



Signal Name 


Direction 


Description 


Receive Interface 


RxClk 


ATM to PHY 


Timing signal for transfer 


RxClav[0] 


PHY to ATM 


Asserted to indicate to the ATM Layer that the PHY Layer has a 

cell ready for transfer to the ATM Layer 

(de-asserted at the end of the cell transfer) 


RxEnb* 


ATM to PHY 


Asserted to indicate that the ATM Layer will sample and accept 
data during the next clock cycle 


RxSOC 


PHY to ATM 


Identifies the cell boundary on RxData 


RxData[7..0] 


PHY to ATM 


ATM Cell Data transfer (8-bit mode) 


RxAddr[4..0] 


ATM to PHY 


PHY device address to select the device that will be active or 
polled for RxClav status 


RxRef* 


PHY to ATM 


Network Timing Reference (8 kHz timing signal) 
(only aty-R interface) 



More details on the UTOPIA Level 2 interface can be found in the ATM Forum Specification, af-phy-0039.000. 
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Annex B (informative): 
TC Example Algorithms 

B.1 Frame Delineation Algorithm 

The transmission frame delineation algorithm is based on Sync_Events (Syncword detection at the expected locations). 
The frame delineation state machine, comprising HUNT, PRESYNC and SYNC states, is shown in figure B.l. 



Violated Sync_Event 
at expected position 



One Sync_Event detected 





m consecutive n consecutive 

Violated Sync_Events Sync_Events Confirmed 

at expected position at expected position 




Figure B.1 : Frame Delineation State lUlachine 

In HUNT state the frame synchronisation is lost and the state machine attempts to acquire frame synchronisation by 
searching the frame Sync_Event. After the first Sync_Event occurs the state machine transits from HUNT state to 
PRESYNC state. 

The state machine transits from PRESYNC state to SYNC state when the frame Sync_Event occurs consecutively at 
least n = 2 times. If a violated Sync_Event occurs during PRESYNC state the state machine transits back to HUNT 
state. 

The state machine transits from SYNC state to HUNT state when the frame Sync_Event is violated consecutively at 
least m = 6 times for the rates lower than 26 Mb/s and at least m = 8 times for the higher rates. 



B.2 Convolutional Interleaver 
B.2.1 Implementation Example 

The interleaving is performed at the transmitter side by writing the octets of the incoming Reed-Solomon codeword into 
a bank of / virtual shift registers numbered] =0, 1, ... (I-l). The length of virtual shift register j in the interleaving 
memory is: M x j. 

The de-interleaving is performed at the received side by writing the octets of the incoming codeword into a bank of / 
virtual shift registers numbered j = 0, 1, ... (/ -1). The length of virtual shift register j in the de-interleaving memory is: 
Mx(I-]-j). 
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The codeword is input either into the interleaving or de-interleaving memory by blocks of / octets at a time. The first 
octet from the codeword is written into the first shift register, the second octet into the second shift register and so on, 
up to the register (/-7). This process is repeated Nil times until the complete codeword is input into the bank of shift 
registers. 

The codeword is output from the interleaving or de-interleaving memory by reading blocks of / octets at a time. The 
first octet from the codeword is read from the first shift register, the second octet from the second shift register and so 
on, up to the register (/-i). This process is repeated Nil times until the complete codeword is extracted from the bank of 
shift registers. 



^^^^ 



1-2 
I-l 



[mI [mI [mI [m 



[mj [mj [mj lmj lmj lmj 

[m] [m] [m] [m] [m] 1 



^ 



\ 

Channel 



HHHH 2 %_out 

-^ [m][m][m] 



M ||M IIM ||M ||M 

[mI [mI [mH [mI [mH [m' 

1 



HH .... 

\K\ 1-2 

E i-i 



Figure B.2: Interleaver/De-interleaver Implementation example 

Figure B.2 shows the structure of the interleaver. The /parallel branches, numbered 0, 1. .. {I-l) are implemented with a 
delay increment of M'*I octets per branch. Each branch is a shift register with the length of QxMxI, Mxl, 2MxI, 
..(/-7)xMx/ bytes. The de -interleaver is similar to the interleaver, but the branch indexes are reversed so that the largest 
interleaver delay corresponds to the smallest de -interleaver delay. De-interleaver synchronization is achieved by routing 
the first octet of an interleaved block of / bytes into the branch 0. 



B.2. 2 Interleaving Parameters - Example 

Some typical examples of interleaving parameters values of M, E and end-to-end delay calculated for Nil - 
different line rates are presented in table B.l. 



8, f = 8 and 



Table B.1 : Interleaving depth Parameter values 



Line Rate, Mb/s 


1,62 


3,24 


6,48 


12,96 


25,92 


51,84 


Value of N/l 


8 


250 [IS of 
erasure correction 


IVI, octets 


2 


4 


8 


16 


32 


64 


Delay, msec 


5,9 


500 us of 
erasure correction 


IVI, octets 


4 


8 


16 


32 


64 


128 


Delay, msec 


11,8 
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Annex C (informative): 
Provisional handshake parameters 



Table C.I : Void 



Table C.2: Carrier sets for the 4,3125 kHz signalling family 



Carrier set 
designation 


Upstream carrier sets 


Downstream carrier sets 


Transmission 
mode 


Frequency 

indices 

(N) 


IVIaximum power 

level/carrier 

(dBm) 


Frequency 

indices 

(N) 


Maximum power 

level/carrier 

(dBm) 


A43 


9,17,25 


-1,65 


40, 56, 64 


-3,65 


duplex only 


B43 


37, 45, 53 


-1,65 


72, 88, 96 


-3,65 


duplex only 


C43 


7,9 


-1,65 


12, 14,64 


-3,65 


duplex only 


D43 


TBD 


TBD 


TBD 


TBD 


duplex only 



Table C.3: Mandatory carrier sets 



xDSL Recommendation(s) 


Carrier set designation 


ITU-T Recommendation G. 992.1 [4], annex A, 
ITU-T Recommendation G.992.2 [5], annex A/B 


A43 


ITU-T Recommendation G.992 [5], annex B 


B43 


ITU-T Recommendation G.992. 1 [4], annex 0, 
ITU-T Recommendation G.992.2 [5], annex 0, 
ITU-T Recommendation G.992. 1 [4], annex H 


043 


ETSI MOM VDSL 


D43 



Table C.4: Standard information field - SPar(1) coding - Octet 1 



SPar(1)s - Octet 1 

G.992. 1 -annex A 

G.992. 1 - annex B 

G.992. 1 - annex 

G.992.2 - annex A/B 

G.992.2 - annex 

G.992. 1 - annex H 

Reserved for allocation by the ITU-T 

No parameters in this octet 



Bits 
















8 




7 


6 


5 


4 


3 


2 


1 


X 




X 


X 


X 


X 


X 


X 


1 


X 




X 


X 


X 


X 


X 


1 


X 


X 




X 


X 


X 


X 


1 


X 


X 


X 




X 


X 


X 


1 


X 


X 


X 


X 




X 


X 


1 


X 


X 


X 


X 


X 




X 


1 


X 


X 


X 


X 


X 


X 




1 


X 


X 


X 


X 


X 


X 


X 


























Table C.5: Standard information field - SPar(1) coding - Octet 2 



SPar(1)s-0ctet2 

G.992. 1 -annex A 

G.992. 1 - annex B 

OommitteeTI DMT VDSL 

Reserved for allocation by the committee T1 

ETSI MOM VDSL 

ETSI SOM VDSL 

Reserved for allocation by the ITU-T 

No parameters in this octet 



Bits 
















8 




7 


6 


5 


4 


3 


2 


1 


X 




X 


X 


X 


X 


X 


X 


1 


X 




X 


X 


X 


X 


X 


1 


X 


X 




X 


X 


X 


X 


1 


X 


X 


X 




X 


X 


X 


1 


X 


X 


X 


X 




X 


X 


1 


X 


X 


X 


X 


X 




X 


1 


X 


X 


X 


X 


X 


X 




1 


X 


X 


X 


X 


X 


X 


X 
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Annex D (informative): 
MClVI Duplexing 

D.1 Introduction 

In Multi -carrier VDSL, N orthogonal narrow-band channels (or tones) are modulated with QAM symbols at the symbol 
rate. For each symbol period the N modulated tones are summed to form a time-domain block of 2N (real) samples. 
These blocks are cyclically extended (to a total length of 2NH-CE) before transmission. The most efficient 
implementation of DMT modulation is through the use of an IFFT. 

At the receiving side 2N samples are extracted from the time-domain signal during each symbol period. An FFT is used 
to demodulate the signal and recover the original QAM symbols on the N tones. Obviously, the receiver has to be 
symbol-aligned with the transmitter such that the 2N samples that are fed to the FFT belong to the same transmitted 
DMT symbol. Only when this is the case are the N tones orthogonal. This means that any given tone will not exhibit 
sidelobe energy on any of the other tones. Put differently; only the energy transmitted on a tone will contribute to the 
received energy on that tone. 

In reality of course, the received signal does not only consist of the useful received signal. The near-end echo and 
near-end crosstalk from transmissions in the opposite direction will also contribute to the received signal and will 
therefore be present in the 2N samples that are sent to the FFT. In general this crosstalk signal is not symbol-aligned 
with the transmitted signal. Usually, the 2N samples that go into the FFT contain contributions from two consecutive 
"crosstalk symbols". The energy from the crosstalkers is consequently not orthogonal to the useful received signal. This 
means that the crosstalk energy will also affect the useful received signal, even if the crosstalk was generated by a 
signal that uses tones in the other transmission direction. 

One way of dealing with the NEXT or echo sidelobes is by filtering the transmitted signal, such that the sidelobe energy 
of the signal (and hence the crosstalk) is reduced. 



D.2 IVICIVI duplexing technique 

Orthogonal DMT duplexing provides a way to separate the useful signal and the near-end crosstalk or echo. 

As explained above, the problem of the sidelobe energy from crosstalk signals is caused by the fact that these "crosstalk 
symbols" are not aligned with the received symbols. If one aligns all transmit and receive signals, also the near-end 
crosstalk and the echo are aligned with the received symbols. The crosstalk symbols will then remain orthogonal to the 
useful signal and there will be no interference on the "receive tones". 

Aligning the two transmission directions is easily done at one side of the modem pair (in fact such single-ended 
alignment is used in some ADSL implementations to simplify the echo-cancelling). In general however, alignment at 
one side results in a misalignment at the other side of the modem pair. The essence of the duplexing is that it provides a 
technique to achieve alignment on both sides simultaneously. This is done by the use of the "cyclic suffix" and "timing 
advance", which are explained in the following sections. 



D.2.1 Cyclic Suffix (CS) 



Because of the transmission delay of the line, it is normally not possible to align transmit and receive symbol at both 
sides simultaneously. Assume the one-way delay of the line is denoted as A. If transmit and receive symbols are 
perfectly aligned at the LT side, there will clearly be a misalignment at the NT side. Indeed, for the alignment at the LT 
to hold, the symbol at the NT has to be transmitted at time -A. On the other hand, the symbol from the LT will arrive at 
the NT at time A resulting in a misalignment of 2A between transmit and receive at the NT. 



£75/ 



156 ETSI TS 101 270-2 VI .2.1 (2003-07) 

This problem can be solved by cyclically extending the transmitted symbols. This is called the cyclic suffix (CS). If for 
example the symbols are extended by 2A it is possible at both sides of the link to chose 2N samples such that these 
samples contain contributions from only one received DMT symbol and only one crosstalk DMT symbol. At both LT 
and NT, the crosstalk will then be orthogonal with the received signal. No additional filtering is needed, since the FFT 
will separate the useful signal and the near-end echo or crosstalk onto different tones. 



D.2.2 Timing Advance (TA) 



As discussed above, a choice of CS = 2A will allow one to keep the signal and the echo (or crosstalk) orthogonal. 
However, it is not the optimal choice for the cyclic extension. In fact, the transmitted symbols at the LT can be 
advanced with A w.r.t. to received symbols. It is then still possible to select 2N samples at both sides such that signal 
and noise remain orthogonal. However, an important advantage is that the required cyclic suffix can be kept as low as 
A, the one-way delay of the line (instead of 2A). 

Conceptually, this corresponds to a situation where LT and NT start transmission of each DMT symbol at different ends 
of the line at the same absolute moment in time. In a practical implementation it requires that the system is capable of 
starting its transmission at a suitable time TA before the arrival of the DMT symbol from the opposite transmission 
direction. 

As a conclusion, one can avoid the sidelobes coming from transmissions in the opposite direction by a suitable 
combination of cyclic extension and timing advance. This only requires operations in the digital domain. No additional 
filtering is required to obtain the desired orthogonality. 



D.3 Synchronous versus asynchronous operation 

When the transmit and receive symbols of all systems in a binder are aligned, both the near-end echo and the near-end 
crosstalk will be orthogonal to the received signal. This obviously requires the synchronisation of all systems is a 
binder. This may not be always possible in practice. This mode is therefore only optional. 

When only transmit and receive symbols of a single system are aligned, the near-end echo will not interfere with the 
received signal. However, the system will still experience the effect of the NEXT from other MCM VDSL systems in 
the same binder that are not aligned to the first system. To reduce the effect of the sidelobes coming from 
non-synchronised systems, all MCM VDSL systems apply windowing at the transmitter. Windowing achieves much 
steeper sidelobes and lower out-of-band PSD levels. 
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